Re: [yocto] [meta-selinux] zeus branch creation

[Joe MacDonald]

[[yocto] [meta-selinux] zeus branch creation] On 19.11.01 (Fri 14:02) Vincent 
Prince wrote:

> Hi team,
> 
> Would it be possible to create zeus branch for meta-selinux layer?

Yes, for sure.  Thanks for the reminder.

-- 
-Joe MacDonald.
Linux Architect | Mentor® A Siemens Business
:wq


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux] Warrior branch glib/meson problem

[Joe MacDonald]

Hi Vincent,

[[yocto] [meta-selinux] Warrior branch glib/meson problem] On 19.10.17 (Thu 
12:50) Vincent Prince wrote:

> Hi Team,
> 
> I have a problem with meta-selinux layer on warrior branch, especially 
> building
> glib-2.0 with meson.
> This commit introduces enabled/disabled flags instead of true/false:
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?h=warrior&id=
> bb0c9c3abcb935e4b362eb57985e1ee7fec0bfe0
> 
> But current glib-2.0 is not 2.60 yet:
> https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-core/glib-2.0/?h=
> warrior
> 
> Can we revert this patch on warrior?

Sorry, I've been away from meta-selinux the last couple of weeks, I'm
addressing the warrior (and other patches in the backlog) right now.

-- 
-Joe MacDonald.
:wq


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][warrior][PATCH] compat: remove thud from warrior layer compatibility list

[Joe MacDonald]

Based on this discussion:
https://www.mail-archive.com/yocto@yoctoproject.org/msg45785.html the
warrior branch does not build against oe-core thud any longer.  Since
that's not really intended to be a supported use caes anyway, remove the
layer compatibility statement for thud.

Signed-off-by: Joe MacDonald 
---
 conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 9dd34b1..b10bd76 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -18,7 +18,7 @@ BBFILE_PRIORITY_selinux = "5"
 # cause compatibility issues with other layers
 LAYERVERSION_selinux = "1"
 
-LAYERSERIES_COMPAT_selinux = "thud warrior"
+LAYERSERIES_COMPAT_selinux = "warrior"
 
 LAYERDEPENDS_selinux = " \
 core \
-- 
2.20.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-selinux thud compatibility

[Joe MacDonald]

Hi Lorenz,

[meta-selinux thud compatibility] On 19.09.17 (Tue 15:08) Lorenz Kofler wrote:

> Hello,
> 
> according to your layer.conf file is the meta-selinux layer compatible with
> thud, however it did not build successfully.
> I had to revert the patch eafe868098f52b061422bffc13fbc582d687d4ed.
> Is it possible to make a Yocto version dependent .bbappend file? Or maybe just
> remove compatibility for thud.

Thanks for bringing this to our attention.  I haven't built thud in
ages, so it's definitely helpful to hear about any issues someone may
be having.

That said, I don't see eafe868098f52b061422bffc13fbc582d687d4ed on the
'thud' branch.  I did a fresh clone into a new workspace from
git://git.yoctoproject.org/meta-selinux just to be sure.  Are you sure
your tree is in sync with the meta-selinux thud brach?  The HEAD commit
there, as I see it, is:

commit fb6192aa2c5df8e80c5e6d4fa5448d574332f68f (HEAD -> thud,
origin/thud)
Author: Khem Raj 
Date:   Tue Feb 26 11:44:43 2019 -0800

refpolicy: Forward patch to apply cleanly on thud

Also fix devtool generated warnings by refreshing patches

    Signed-off-by: Khem Raj 
Signed-off-by: Joe MacDonald 

-- 
-Joe MacDonald.
Linux Architect | Mentor® A Siemens Business
:wq


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] conf/layer.conf: use BBFILES_DYNAMIC for dynamic layers

[Joe MacDonald]

[Re: [meta-selinux][PATCH] conf/layer.conf: use BBFILES_DYNAMIC for dynamic 
layers] On 19.09.11 (Wed 09:22) Yi Zhao wrote:

> 
> On 9/10/19 1:11 AM, Joe MacDonald wrote:
> > Hi Yi,
> > 
> > [[meta-selinux][PATCH] conf/layer.conf: use BBFILES_DYNAMIC for dynamic 
> > layers] On 19.09.09 (Mon 14:01) Yi Zhao wrote:
> > 
> > > From: Robert Yang 
> > > 
> > > The previous code add all BBFILE_COLLECTIONS/recipes*/*/*.bbappend to 
> > > BBFILES,
> > > which causes the parsing very slow when there are many layers, e.g., I 
> > > have 87
> > > layers:
> > > 
> > > * Before:
> > > $ rm -fr tmp-glibc/ cache; time bitbake -p
> > > real0m45.173s
> > > user0m0.560s
> > > sys 0m0.060s
> > > 
> > > * After:
> > > $ rm -fr tmp-glibc/ cache; time bitbake -p
> > > real0m25.542s
> > > user0m0.572s
> > > sys 0m0.040s
> > > 
> > > It wasted 20s which wasn't worth (The host has 128 threads, it should 
> > > cost more
> > > time on less power host), use BBFILES_DYNAMIC can fix the problem.
> > 
> > This seems like a big claim, I certainly haven't seen that on my setup:
> > 
> > * Before:
> > $ rm -fr tmp cache
> > real0m14.751s
> > user0m0.323s
> > sys 0m0.048s
> > 
> > * After:
> > $ rm -fr tmp cache ; time bitbake -p
> > real0m14.725s
> > user0m0.326s
> > sys 0m0.046s
> > 
> > but it's still a sensible change.  When I ran a test before/after
> > configuration for augeas the configuration seemed off, though.  Can you
> > confirm that with this change as is you're getting the correct
> > --with/--without and --enable/--disable and patches applied for your
> > layers?  I just want to confirm since the ~20s difference in parsing
> > seems kind of out of scale for moving essentially three bbappends around
> > and I'm wondering if there's something else siginficant in your tree we
> > want to consider.
> 
> 
> This patch is from Robert Yang. CC to him. Maybe he can give us more
> explanation.
> 
> For the augeas, the current augeas_%.bbapend doesn't work because the augeas
> recipe is in meta-oe layer but not meta-python layer. This patch moves the
> bbappend to the correct layer to fix this issue.
> 
> It works on my local:
> 
> $ cat log.do_configure
> 
> [snip]
> checking for library containing setfilecon... -lselinux
> [snip]
> checking for selinux/selinux.h... (cached) yes
> checking selinux/context.h usability... yes
> checking selinux/context.h presence... yes
> checking for selinux/context.h... yes
> [snip]

Okay, thanks.  Funny that I randomly picked the package that was broken
in multiple ways, but this looks like an improvement overall.

-J.

> 
> 
> //Yi
> 
> 
> > 
> > -J.
> > 
> > > Signed-off-by: Robert Yang 
> > > Signed-off-by: Yi Zhao 
> > > ---
> > >   conf/layer.conf   | 11 
> > > +++
> > >   .../recipes-daemons/iscsi-initiator-utils/files/initd.debian  |  0
> > >   .../iscsi-initiator-utils/iscsi-initiator-utils_%.bbappend|  0
> > >   .../iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc   |  0
> > >   .../recipes-support}/augeas/augeas_%.bbappend |  0
> > >   .../recipes-containers/lxc/lxc_%.bbappend |  0
> > >   6 files changed, 7 insertions(+), 4 deletions(-)
> > >   rename {networking-layer => 
> > > dynamic-layers/networking-layer}/recipes-daemons/iscsi-initiator-utils/files/initd.debian
> > >  (100%)
> > >   rename {networking-layer => 
> > > dynamic-layers/networking-layer}/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_%.bbappend
> > >  (100%)
> > >   rename {networking-layer => 
> > > dynamic-layers/networking-layer}/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc
> > >  (100%)
> > >   rename {meta-python/recipes-extended/augeas => 
> > > dynamic-layers/openembedded-layer/recipes-support}/augeas/augeas_%.bbappend
> > >  (100%)
> > >   rename {virtualization-layer => 
> > > dynamic-layers/virtualization-layer}/recipes-containers/lxc/lxc_%.bbappend
> > >  (100%)
> > > 
> > > diff --git a/conf/layer.conf b/conf/layer.conf
> > > index 9dd34b1..89b9468 100644
> > > --- a/conf/layer.conf
> > > +++ b/conf/layer.conf
> > > @@

Re: [yocto] [meta-selinux][PATCH] conf/layer.conf: use BBFILES_DYNAMIC for dynamic layers

[Joe MacDonald]

nitiator-utils/iscsi-initiator-utils_%.bbappend
> similarity index 100%
> rename from 
> networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_%.bbappend
> rename to 
> dynamic-layers/networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_%.bbappend
> diff --git 
> a/networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc
>  
> b/dynamic-layers/networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc
> similarity index 100%
> rename from 
> networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc
> rename to 
> dynamic-layers/networking-layer/recipes-daemons/iscsi-initiator-utils/iscsi-initiator-utils_selinux.inc
> diff --git a/meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend 
> b/dynamic-layers/openembedded-layer/recipes-support/augeas/augeas_%.bbappend
> similarity index 100%
> rename from meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend
> rename to 
> dynamic-layers/openembedded-layer/recipes-support/augeas/augeas_%.bbappend
> diff --git a/virtualization-layer/recipes-containers/lxc/lxc_%.bbappend 
> b/dynamic-layers/virtualization-layer/recipes-containers/lxc/lxc_%.bbappend
> similarity index 100%
> rename from virtualization-layer/recipes-containers/lxc/lxc_%.bbappend
> rename to 
> dynamic-layers/virtualization-layer/recipes-containers/lxc/lxc_%.bbappend
> -- 
> 2.7.4
> 

-- 
-Joe MacDonald.
Linux Architect | Mentor® A Siemens Business
:wq


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] selinux-autorelabel: disable enforcing mode before relabel

[Joe MacDonald]

[Re: [meta-selinux][PATCH] selinux-autorelabel: disable enforcing mode before 
relabel] On 19.09.06 (Fri 11:31) Yi Zhao wrote:

> 
> On 9/5/19 7:57 PM, Joe MacDonald wrote:
> > [[meta-selinux][PATCH] selinux-autorelabel: disable enforcing mode before 
> > relabel] On 19.09.05 (Thu 16:57) Yi Zhao wrote:
> > 
> > > The commit b0d31db104d9a4e94bc1409c2ffcc1d82f4a780f introduced an issue
> > > when first boot with bootparams="selinux=1 enforcing=1". At first boot,
> > > all files are unlabeled including /sbin/fixfiles. The relabel operation
> > > is not permitted under enforcing mode. Set /sys/fs/selinux/enforce to 0
> > > to ensure the enforcing mode is disabled before relabel.
> > Did you try this with '/usr/sbin/setenforce 0' instead?  The rationale
> > makes sense but going straight at sysfs like that isn't the right
> > approach intuitively.  If that's not working, please just include a bit
> > of an explanation for why this is the best option.
> 
> It also works with setenforce.
> 
> I referred to the selinux-autorelabel script on Fedora 30, it uses `echo "0"
> > /sys/fs/selinux/enforce` to disables enforcing mode:
> 
> cat /usr/libexec/selinux/selinux-autorelabel
> 
> [snip]
>  32 relabel_selinux() {
>  33 # if /sbin/init is not labeled correctly this process is running
> in the
>  34 # wrong context, so a reboot will be required after relabel
>  35 AUTORELABEL=
>  36 . /etc/selinux/config
>  37 echo "0" > /sys/fs/selinux/enforce
>  38 [ -x /bin/plymouth ] && plymouth --quit
>  39
> [snip]

Okay, but our version of the script is much less complex than the Fedora
one and we already have the precedent of calling fixfiles by full path
and variable, I'd rather keep the script consistent in style.  If you
want to propose replacing our selinux-autorelabel.sh with the one from
Fedora, please submit a patch for that, but for this patch I'd just
rather see the style remain consistent with what's already there.

Thanks.
-J.

> 
> 
> //Yi
> 
> 
> > 
> > Thanks.
> > -J.
> > 
> > > Signed-off-by: Yi Zhao 
> > > ---
> > >   recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh | 1 
> > > +
> > >   1 file changed, 1 insertion(+)
> > > 
> > > diff --git 
> > > a/recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh 
> > > b/recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh
> > > index 154dad1..cb40971 100644
> > > --- a/recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh
> > > +++ b/recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh
> > > @@ -13,6 +13,7 @@ fi
> > >   # If /.autorelabel placed, the whole file system should be relabeled
> > >   if [ -f /.autorelabel ]; then
> > >   echo "SELinux: /.autorelabel placed, filesystem will be 
> > > relabeled..."
> > > + echo "0" > /sys/fs/selinux/enforce
> > >   ${FIXFILES} -F -f relabel
> > >   /bin/rm -f /.autorelabel
> > >   echo " * Relabel done, rebooting the system."
> > > -- 
> > > 2.7.4
> > > 

-- 
-Joe MacDonald.
Linux Architect | Mentor® A Siemens Business
:wq


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] selinux-init: use systemd (re)labelling

[Joe MacDonald]

s-security/selinux/selinux-init_0.1.bb index 38b5900..78f571c
> > 100644
> > --- a/recipes-security/selinux/selinux-init_0.1.bb
> > +++ b/recipes-security/selinux/selinux-init_0.1.bb
> > @@ -14,9 +14,11 @@ ${PN}_RDEPENDS = " \
> >  policycoreutils-setfiles \
> >  "
> > 
> > -SRC_URI = "file://${BPN}.sh \
> > -   file://${BPN}.service \
> > -   "
> > +SRC_URI = " \
> > +file://${BPN}.sh \
> > +file://${BPN}.sh.sysvinit \
> > +file://${BPN}.service \
> > +"
> > 
> >  INITSCRIPT_PARAMS = "start 01 S ."
> > 
> > diff --git a/recipes-security/selinux/selinux-initsh.inc
> > b/recipes-security/selinux/selinux-initsh.inc index bcdd449..8e31cda 100644
> > --- a/recipes-security/selinux/selinux-initsh.inc
> > +++ b/recipes-security/selinux/selinux-initsh.inc
> > @@ -17,9 +17,15 @@ inherit update-rc.d systemd
> > 
> >  SYSTEMD_SERVICE_${PN} = "${SELINUX_SCRIPT_SRC}.service"
> > 
> > +FILES_${PN} += "/.autorelabel"
> > +
> >  do_install () {
> > install -d ${D}${sysconfdir}/init.d/
> > install -m 0755 ${WORKDIR}/${SELINUX_SCRIPT_SRC}.sh
> > ${D}${sysconfdir}/init.d/${SELINUX_SCRIPT_DST} +# Insert the relabelling
> > code which is only needed with sysvinit +   sed -i -e '/HERE/r
> > ${WORKDIR}/${SELINUX_SCRIPT_SRC}.sh.sysvinit' \ +  -e '/.*HERE$/d' 
> > -e
> > '/.*Contents.*sysvinit/d' \
> > +  ${D}${sysconfdir}/init.d/${SELINUX_SCRIPT_DST}
> > 
> > install -d ${D}${systemd_unitdir}/system
> > install -m 0644 ${WORKDIR}/${SELINUX_SCRIPT_SRC}.service
> > ${D}${systemd_unitdir}/system @@ -27,6 +33,8 @@ do_install () {
> > if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 
> 'false',
> > d)}; then install -d ${D}${bindir}
> > install -m 0755 ${WORKDIR}/${SELINUX_SCRIPT_SRC}.sh ${D}$
> {bindir}
> > +   sed -i -e '/.*HERE$/d' ${D}${bindir}/$
> {SELINUX_SCRIPT_SRC}.sh
> > +   echo "# first boot relabelling" > ${D}/.autorelabel
> > fi
> >  }
> 
> 
> 
> 

-- 
-Joe MacDonald.
Linux Architect | Mentor® A Siemens Business
:wq
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] selinux-autorelabel: disable enforcing mode before relabel

[Joe MacDonald]

[[meta-selinux][PATCH] selinux-autorelabel: disable enforcing mode before 
relabel] On 19.09.05 (Thu 16:57) Yi Zhao wrote:

> The commit b0d31db104d9a4e94bc1409c2ffcc1d82f4a780f introduced an issue
> when first boot with bootparams="selinux=1 enforcing=1". At first boot,
> all files are unlabeled including /sbin/fixfiles. The relabel operation
> is not permitted under enforcing mode. Set /sys/fs/selinux/enforce to 0
> to ensure the enforcing mode is disabled before relabel.

Did you try this with '/usr/sbin/setenforce 0' instead?  The rationale
makes sense but going straight at sysfs like that isn't the right
approach intuitively.  If that's not working, please just include a bit
of an explanation for why this is the best option.

Thanks.
-J.

> 
> Signed-off-by: Yi Zhao 
> ---
>  recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh 
> b/recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh
> index 154dad1..cb40971 100644
> --- a/recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh
> +++ b/recipes-security/selinux/selinux-autorelabel/selinux-autorelabel.sh
> @@ -13,6 +13,7 @@ fi
>  # If /.autorelabel placed, the whole file system should be relabeled
>  if [ -f /.autorelabel ]; then
>   echo "SELinux: /.autorelabel placed, filesystem will be relabeled..."
> + echo "0" > /sys/fs/selinux/enforce
>   ${FIXFILES} -F -f relabel
>   /bin/rm -f /.autorelabel
>   echo " * Relabel done, rebooting the system."
> -- 
> 2.7.4
> 


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH 3/3] util-linux: drop obsolete patch

[Joe MacDonald]

[Re: [yocto] [meta-selinux][PATCH 3/3] util-linux: drop obsolete patch] On 
19.08.29 (Thu 16:00) Yi Zhao wrote:

> Hi Joe,
> 
> 
> Seems you were missing this patch. Would you please merge it? Thanks.

Oh, yeah, sure.  It got classified as spam.  Since it was the end of a
queue I just assumed they were mis-numbered when I only found 1/3 and
2/3.

Thanks for pinging me on it.

-J.

> 
> 
> //Yi
> 
> 
> On 5/20/19 12:41 PM, Yi Zhao wrote:
> > Signed-off-by: Yi Zhao 
> > ---
> >   .../util-linux/fix-libmount_la_DEPENDENCIES.patch  | 28 
> > --
> >   1 file changed, 28 deletions(-)
> >   delete mode 100644 
> > recipes-core/util-linux/util-linux/fix-libmount_la_DEPENDENCIES.patch
> > 
> > diff --git 
> > a/recipes-core/util-linux/util-linux/fix-libmount_la_DEPENDENCIES.patch 
> > b/recipes-core/util-linux/util-linux/fix-libmount_la_DEPENDENCIES.patch
> > deleted file mode 100644
> > index ab54818..000
> > --- a/recipes-core/util-linux/util-linux/fix-libmount_la_DEPENDENCIES.patch
> > +++ /dev/null
> > @@ -1,28 +0,0 @@
> > -Subject: [PATCH] util-linux: fix libmount_la_DEPENDENCIES.
> > -
> > -Upstream-Status: Pending
> > -
> > -libmount_la_LIBADD contains "-lselinux", this is not a object that
> > -could consider as a dependency target. So fix this.
> > -
> > -Signed-off-by: Xin Ouyang 
> > 
> > - libmount/src/Makemodule.am |2 +-
> > - 1 files changed, 1 insertions(+), 1 deletions(-)
> > -
> > -diff --git a/libmount/src/Makemodule.am b/libmount/src/Makemodule.am
> > -index 494e02a..bf494a4 100644
> >  a/libmount/src/Makemodule.am
> > -+++ b/libmount/src/Makemodule.am
> > -@@ -38,7 +38,7 @@ libmount_la_CFLAGS = \
> > -   -I$(top_srcdir)/libmount/src
> > -
> > - libmount_la_DEPENDENCIES = \
> > --  $(libmount_la_LIBADD) \
> > -+  libcommon.la libblkid.la \
> > -   libmount/src/libmount.sym \
> > -   libmount/src/libmount.h.in
> > -
> > ---
> > -1.7.5.4
> > -

-- 
-Joe MacDonald.
Linux Architect | Mentor® A Siemens Business
:wq


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux] [PATCH] python-scapy: upgrade 2.4.2 -> 2.4.3

[Joe MacDonald]

[Re: [yocto] [meta-selinux] [PATCH] python-scapy: upgrade 2.4.2 -> 2.4.3] On 
19.08.29 (Thu 07:14) akuster808 wrote:

> 
> 
> On 8/28/19 10:41 PM, Yuan Chao wrote:
> > License file changed from bin/scapy to LICENSE
> Is this the correct layer?

There's no scapy in meta-selinux, AFAIK.  So proably this was destined
for meta-security instead.

-J.

> 
> -armin
> >
> > Signed-off-by: Yuan Chao 
> > ---
> >  recipes-security/scapy/python-scapy.inc   | 4 ++--
> >  .../scapy/{python-scapy_2.4.2.bb => python-scapy_2.4.3.bb}| 0
> >  .../scapy/{python3-scapy_2.4.2.bb => python3-scapy_2.4.3.bb}  | 0
> >  3 files changed, 2 insertions(+), 2 deletions(-)
> >  rename recipes-security/scapy/{python-scapy_2.4.2.bb => 
> > python-scapy_2.4.3.bb} (100%)
> >  rename recipes-security/scapy/{python3-scapy_2.4.2.bb => 
> > python3-scapy_2.4.3.bb} (100%)
> >
> > diff --git a/recipes-security/scapy/python-scapy.inc 
> > b/recipes-security/scapy/python-scapy.inc
> > index baa69b2..28e13f2 100644
> > --- a/recipes-security/scapy/python-scapy.inc
> > +++ b/recipes-security/scapy/python-scapy.inc
> > @@ -3,11 +3,11 @@ DESCRIPTION = "Scapy is a powerful interactive packet 
> > manipulation program. It i
> >  SECTION = "security"
> >  LICENSE = "GPLv2"
> >  
> > -LIC_FILES_CHKSUM = 
> > "file://bin/scapy;beginline=9;endline=13;md5=1d5249872cc54cd4ca3d3879262d0c69"
> > +LIC_FILES_CHKSUM = "file://LICENSE;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> >  
> >  S = "${WORKDIR}/git"
> >  
> > -SRCREV = "bad14cb1a5aee29f8107fbe8ad008d4645f14da7"
> > +SRCREV = "3047580162a9407ef05fe981983cacfa698f1159"
> >  SRC_URI = "git://github.com/secdev/scapy.git"
> >  
> >  inherit ptest
> > diff --git a/recipes-security/scapy/python-scapy_2.4.2.bb 
> > b/recipes-security/scapy/python-scapy_2.4.3.bb
> > similarity index 100%
> > rename from recipes-security/scapy/python-scapy_2.4.2.bb
> > rename to recipes-security/scapy/python-scapy_2.4.3.bb
> > diff --git a/recipes-security/scapy/python3-scapy_2.4.2.bb 
> > b/recipes-security/scapy/python3-scapy_2.4.3.bb
> > similarity index 100%
> > rename from recipes-security/scapy/python3-scapy_2.4.2.bb
> > rename to recipes-security/scapy/python3-scapy_2.4.3.bb
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
-Joe MacDonald.
Linux Architect | Mentor® A Siemens Business
:wq


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH 1/2] meson-selinux.bbclass: fix meson flags for glib-2.0-native

[Joe MacDonald]

Hi Mikko,

Is this specifically for warrior (or thud), maybe?  The following commit
explains the current logic:

commit bb0c9c3abcb935e4b362eb57985e1ee7fec0bfe0
Author: Yi Zhao 
Date:   Wed Jun 12 15:53:20 2019 +0800

glib-2.0: fix configure error for meson build

In glib 2.60.x, it turns selinux into a meson feature. We should use
'-Dselinux=enabled/disabled' rather than '-Dselinux=true/false' to
enable/disable the feature.

Add meso-enable-selinux.bbclass for this change and inherit it in
glib-2.0 bbappend to fix the configure error.

Signed-off-by: Yi Zhao 
        Signed-off-by: Joe MacDonald 

and the second patch is already present in tree:

commit 087fe5c8144c246c6361bd8bcbd1ffd9e9b675bb
Author: Yi Zhao 
Date:   Fri Aug 9 17:48:00 2019 +0800

libselinux: fix build with glibc 2.30

Fix build error:
procattr.c:27:14: error: static declaration of 'gettid' follows
non-static declaration
   27 | static pid_t gettid(void)
  |  ^~
In file included from 
/buildarea/build/tmp/work/core2-64-poky-linux/libselinux/2.8-r0/recipe-sysroot/usr/include/unistd.h:1170,
 from procattr.c:2:

/buildarea/build/tmp/work/core2-64-poky-linux/libselinux/2.8-r0/recipe-sysroot/usr/include/bits/unistd_ext.h:34:16:
note: previous declaration of 'gettid' was here
   34 | extern __pid_t gettid (void) __THROW;
  |^~

Signed-off-by: Yi Zhao 
Signed-off-by: Joe MacDonald 

This is what my current work tree looks like, for reference:

  $ repo forall -p -c git log -1 --pretty=oneline
  project meta-openembedded/
  2ebaa8df1257389161d0bee9e553c28f63e52005 python3-pyatspi: Add Dbus ATSPI 
recipe
  
  project meta-selinux/
  154654a6fe12206a6b9ad6d8c36a4dbe672bcc46 selinux-python: Fix dependency for 
ntpath
  
  project yocto-mainline/
  ca2207f418b7847ffce4b8c53a5a442e5cf461d9 commands.py: fix typo

-J.

[[yocto] [meta-selinux][PATCH 1/2] meson-selinux.bbclass: fix meson flags for 
glib-2.0-native] On 19.08.28 (Wed 18:30) Mikko Rapeli wrote:

> With latest poky master, glib-2.0-native fails to compile:
> 
> | meson.build:1:0: ERROR: Value "false" for combo option is not one of the 
> choices. Possible choices are: "enabled",
>  "disabled", "auto".
> 
> Thus use enabled and disabled when enabling and disabling flags
> with meson. Now glib-2.0-native compiles again.
> 
> Signed-off-by: Mikko Rapeli 
> ---
>  classes/meson-selinux.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/classes/meson-selinux.bbclass b/classes/meson-selinux.bbclass
> index 77a763a..91c2a2b 100644
> --- a/classes/meson-selinux.bbclass
> +++ b/classes/meson-selinux.bbclass
> @@ -1,4 +1,4 @@
>  inherit selinux
>  
>  PACKAGECONFIG_append = " ${@target_selinux(d)}"
> -PACKAGECONFIG[selinux] = "-Dselinux=true,-Dselinux=false,libselinux,"
> +PACKAGECONFIG[selinux] = "-Dselinux=enabled,-Dselinux=disabled,libselinux,"
> -- 
> 1.9.1
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
-Joe MacDonald.
:wq


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] refpolicy: refresh patches

[Joe MacDonald]

Hi Yi,

Where did this patch refresh come from?  Since the goal right now for the
refpolicy recipes is to move to a purely git-based approach, I'd prefer to not
do patch refreshes that don't come from an export of the patched git trees, like
the one I'd mentioned in my earlier email here:

https://www.mail-archive.com/yocto@yoctoproject.org/msg43933.html

Thanks,
-Joe.

[[yocto] [meta-selinux][PATCH] refpolicy: refresh patches] On 19.04.19 (Fri 
14:10) Yi Zhao wrote:

> Refrefsh 0001-refpolicy-minimum-audit-logging-getty-audit-related-.patch
> and 0004-refpolicy-minimum-systemd-mount-logging-authlogin-ad.patch.
> Remove the trailing line: \ No newline at end of file
> 
> Signed-off-by: Yi Zhao 
> ---
>  ...y-minimum-audit-logging-getty-audit-related-.patch |  1 -
>  ...y-minimum-systemd-mount-logging-authlogin-ad.patch | 19 
> ---
>  ...y-minimum-audit-logging-getty-audit-related-.patch |  1 -
>  ...y-minimum-systemd-mount-logging-authlogin-ad.patch | 19 
> ---
>  4 files changed, 16 insertions(+), 24 deletions(-)
> 
> diff --git 
> a/recipes-security/refpolicy/refpolicy-2.20190201/0001-refpolicy-minimum-audit-logging-getty-audit-related-.patch
>  
> b/recipes-security/refpolicy/refpolicy-2.20190201/0001-refpolicy-minimum-audit-logging-getty-audit-related-.patch
> index f92ddb8..10d2bcb 100644
> --- 
> a/recipes-security/refpolicy/refpolicy-2.20190201/0001-refpolicy-minimum-audit-logging-getty-audit-related-.patch
> +++ 
> b/recipes-security/refpolicy/refpolicy-2.20190201/0001-refpolicy-minimum-audit-logging-getty-audit-related-.patch
> @@ -62,7 +62,6 @@ index 63e92a8e..8ab46925 100644
>  +allow auditd_t initrc_t:unix_dgram_socket sendto;
>  +
>  +allow klogd_t initrc_t:unix_dgram_socket sendto;
> -\ No newline at end of file
>  -- 
>  2.19.1
>  
> diff --git 
> a/recipes-security/refpolicy/refpolicy-2.20190201/0004-refpolicy-minimum-systemd-mount-logging-authlogin-ad.patch
>  
> b/recipes-security/refpolicy/refpolicy-2.20190201/0004-refpolicy-minimum-systemd-mount-logging-authlogin-ad.patch
> index 98b6156..65ef55b 100644
> --- 
> a/recipes-security/refpolicy/refpolicy-2.20190201/0004-refpolicy-minimum-systemd-mount-logging-authlogin-ad.patch
> +++ 
> b/recipes-security/refpolicy/refpolicy-2.20190201/0004-refpolicy-minimum-systemd-mount-logging-authlogin-ad.patch
> @@ -33,13 +33,13 @@ Signed-off-by: Shrikant Bobade 
> 
>  Signed-off-by: Joe MacDonald 
>  ---
>   policy/modules/system/authlogin.te | 2 ++
> - policy/modules/system/logging.te   | 7 ++-
> + policy/modules/system/logging.te   | 5 +
>   policy/modules/system/mount.te | 3 +++
>   policy/modules/system/systemd.te   | 5 +
> - 4 files changed, 16 insertions(+), 1 deletion(-)
> + 4 files changed, 15 insertions(+)
>  
>  diff --git a/policy/modules/system/authlogin.te 
> b/policy/modules/system/authlogin.te
> -index 345e07f3..39f860e0 100644
> +index 345e07f..39f860e 100644
>  --- a/policy/modules/system/authlogin.te
>  +++ b/policy/modules/system/authlogin.te
>  @@ -472,3 +472,5 @@ optional_policy(`
> @@ -49,23 +49,20 @@ index 345e07f3..39f860e0 100644
>  +
>  +allow chkpwd_t proc_t:filesystem getattr;
>  diff --git a/policy/modules/system/logging.te 
> b/policy/modules/system/logging.te
> -index 8ab46925..520f7da6 100644
> +index c9991ab..520f7da 100644
>  --- a/policy/modules/system/logging.te
>  +++ b/policy/modules/system/logging.te
> -@@ -627,4 +627,9 @@ allow auditd_t tmpfs_t:file { getattr setattr create 
> open read append };
> - allow auditd_t tmpfs_t:dir { open read search add_name write getattr search 
> };
> +@@ -628,3 +628,8 @@ allow auditd_t tmpfs_t:dir { open read search add_name 
> write getattr search };
>   allow auditd_t initrc_t:unix_dgram_socket sendto;
>   
> --allow klogd_t initrc_t:unix_dgram_socket sendto;
> -\ No newline at end of file
> -+allow klogd_t initrc_t:unix_dgram_socket sendto;
> + allow klogd_t initrc_t:unix_dgram_socket sendto;
>  +
>  +allow syslogd_t self:shm create;
>  +allow syslogd_t self:sem { create read unix_write write };
>  +allow syslogd_t self:shm { read unix_read unix_write write };
>  +allow syslogd_t tmpfs_t:file { read write };
>  diff --git a/policy/modules/system/mount.te b/policy/modules/system/mount.te
> -index 3dcb8493..a87d0e82 100644
> +index 3dcb849..a87d0e8 100644
>  --- a/policy/modules/system/mount.te
>  +++ b/policy/modules/system/mount.te
>  @@ -231,3 +231,6 @@ optional_policy(`
> @@ -76,7 +73,7 @@ index 3dcb8493..a87d0e82 100644
>  +allow mount_t proc_t:filesystem getattr;
>  +allow mount_t initrc_t:udp_socket { read write };
>  diff --git a/policy/modules/system/systemd.te 
> b/policy/modules/system/systemd.te
> -index a6

Re: [yocto] [meta-selinux][PULL] refpolicy: update to 2.20190201 and git HEAD policies (2019-04-10 10:57:14 -0400)

[Joe MacDonald]

Hi all,

Update on this, I've just now completed this merge (with Yi's corrected
SRC_URI for the RELEASE_2.20190201 tag) and I'm going to start pulling
in the additional meta-selinux patches that have been sent to the
mailing list.  I'll prep a queue of those updates soon and send out
another pull mail to the list in order to keep everyone reasonably
informed of what's in and what's not.  Once that happens, if you have a
patch that's still pending but not in my pull list, please let me know
with a follow up to the list.

Thanks,
-J.

[[yocto] [meta-selinux][PULL] refpolicy: update to 2.20190201 and git HEAD 
policies (2019-04-10 10:57:14 -0400)] On 19.04.10 (Wed 11:53) Joe MacDonald 
wrote:

> This is a huge, long-overdue update the refpolicy.  I apologise for it
> blocking the other outstanding meta-selinux patches, but I've been
> trying to limit the scope of changes while this happens.  Now that this
> is cleared off the slate, I'll be gathering up the other meta-selinux
> patches from the list.  I'll send out a follow-up on those as they're
> merged and another when I think I'm done, so if I've missed your patch,
> that'll be the time to ping me about it.
> 
> As for this, here's what I've done.
> 
>   - manually reviewed all patches that had been present in
> repolicy-* for both the old stable (2.20170204) and git
> versions
> 
>   - forked the SELinuxPolicy/refpolicy repo and applied all
> still-relevant patches to the RELEASE_2.20190201 branch
> 
>   - restructured the patches so that all patches that should
> reasonably apply to all variants (mcs, mls, minimum, standard
> and targeted) were in a common branch and only the ones that
> are specific to each variant would be in their own recipe
> 
>   - restructure the patches so that systemd and sysvinit patches
> were not applied to the same tree
> 
>   - created a parallel set of branches for each of these against
> current git HEAD
> 
> The results of this can be examined here:
> 
>   https://github.com/joeythesaint/refpolicy
> 
> Then each of these were exported and put in the appropriate SRC_URIs so
> the branch structure is more-or-less preserved.
> 
> My goals with this approach were the following:
> 
>   - make it easier to keep refpolicy up to date, particularly for
> anyone wanting to use the git variants
> 
>   - make it easier to determine how your preferred version of
> refpolicy on Yocto differs from upstream refpolicy
> 
>   - limit the above differences to the minimum to achieve the goal
> of a functional Yocto system
> 
>   - eventually move us away from release tarballs entirely
> 
> That last point is why I'm preserving the refpolicy fork above.  I'd
> like to keep going with this and so future refpolicy patches will first
> be put in that repo then exported and applied to the SRC_URIs.  If you
> have such a patch and want to send me a PR against the branch you think
> it belongs on from github directly, that'd be awesome, but the old
> method of patches to the mailing list will work fine too, just know that
> this is the way I'm going to try to manage this for the foreseeable
> future.  Ultimately, if this proves to work well, I would like to move
> the refpolicy fork off github and house it on git.yoctoproject.org
> beside meta-selinux, but the workflow needs to be properly validated
> first.
> 
> One additional point, I intend to take another pass at revising this
> stuff, ideally moving the huge number of common patches out as well.
> There's still some that aren't necessary for base yocto but are for
> additional layers.  That's fine for us to have, but I'd like to get
> those moved to optional layer directories so we're making the best use
> of that functionality we can.  If you have suggestions on which pieces
> already present are good candidates, let me know.  Similarly, if you've
> got additional policy patches you want to see included, feel free to
> send them along, we can easily move them to optional locations inside
> meta-selinux.
> 
> Finally, please everyone test this and provide feedback on anything that
> doesn't work or looks strange.  This is easily the biggest change we've
> had in meta-selinux in years and I expect there's still some wrinkles to
> be ironed out.  And I really appreciate everyone's patience while we got
> to this point and hope it's not too much more pain before we put a
> ribbon on this and call it done.
> 
> I'll give this until at least the weekend before merging it to maste

[yocto] [meta-selinux][PULL] consolidated meta-selinux updates

[Joe MacDonald]

Hi all,

This is the promised update to meta-selinux, incorporating all of the
current pending patches I'm aware of on the list.  As before, I'll give
everyone a couple of days to check this out and raise any questions or
concerns before merging it.  Please take a look and let me know if
you've got a pending change that isn't here.  There were a couple that
didn't get merged, but I think the only ones I dropped were due to being
no longer applicable (for example Yi's updates to refpolicy to the 2018
release).



The following changes since commit d6686698444616b9857a15bb514400f8a629e7ed:

  refpolicy: update to 2.20190201 and git HEAD policies (2019-04-12 15:28:38 
-0400)

are available in the Git repository at:

  git://git.yoctoproject.org/meta-selinux yocto/master-next

for you to fetch changes up to e0105eed2b2461bf08b7aaf71db12dfae6ca51e3:

  audit: change to use ${WORKDIR} instead ${S}/../ (2019-04-15 09:02:21 -0400)


Chen Qi (1):
  audit: change to use ${WORKDIR} instead ${S}/../

Kai Kang (2):
  layer.conf: update to warrior release name series
  setools: fix build failure with gcc 7

Luca Boccassi (1):
  packagegroup-selinux-minimal: add selinux-init

Sinan Kaya (1):
  libpcre: do no create links when compiling for windows

Yi Zhao (4):
  core-image-selinux.bb: remove trailing whitespace
  openssh: update sshd_config
  selinux-image.bbclass: using append instead of += for 
IMAGE_PREPROCESS_COMMAND
  selinux: remove git version

 classes/selinux-image.bbclass  |  2 +-
 conf/layer.conf|  2 +-
 recipes-connectivity/openssh/files/sshd_config | 53 +++--
 recipes-security/audit/audit_2.8.4.bb  |  2 +-
 recipes-security/images/core-image-selinux.bb  |  2 +-
 .../packagegroups/packagegroup-selinux-minimal.bb  |  1 +
 recipes-security/selinux/checkpolicy_git.bb|  6 --
 recipes-security/selinux/libselinux_git.bb | 14 
 recipes-security/selinux/libsemanage_git.bb| 17 
 recipes-security/selinux/libsepol_git.bb   |  8 --
 recipes-security/selinux/policycoreutils_git.bb|  6 --
 recipes-security/selinux/selinux_git.inc   | 11 ---
 ...ailure-with-GCC-7-due-to-possible-truncat.patch | 90 ++
 recipes-support/libpcre/libpcre_selinux.inc| 20 +++--
 14 files changed, 118 insertions(+), 116 deletions(-)
 delete mode 100644 recipes-security/selinux/checkpolicy_git.bb
 delete mode 100644 recipes-security/selinux/libselinux_git.bb
 delete mode 100644 recipes-security/selinux/libsemanage_git.bb
 delete mode 100644 recipes-security/selinux/libsepol_git.bb
 delete mode 100644 recipes-security/selinux/policycoreutils_git.bb
 delete mode 100644 recipes-security/selinux/selinux_git.inc

-- 
-Joe MacDonald.
:wq


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PULL] refpolicy: update to 2.20190201 and git HEAD policies (2019-04-10 10:57:14 -0400)

[Joe MacDonald]

Hi Yi,

[Re: [yocto] [meta-selinux][PULL] refpolicy: update to 2.20190201 and git HEAD 
policies (2019-04-10 10:57:14 -0400)] On 19.04.11 (Thu 16:19) Yi Zhao wrote:

> Hi Joe,
> 
> Thank you for working on the refpolicy upgrade.
> I have a quick test with your patch. Here are the results:
> 
> Machine: qemux86-64
> Image: core-image-selinux
> Init manager: systemd
> Boot command: runqemu qemux86-64 kvm nographic bootparams="selinux=1 
> enforcing=
> X" qemuparams="-m 1024"
> 
> 1. All refpolicy type of git version can be built without problems.
> 
> 2. With parameter selinux=1 & enforcing=0
> The qemu can boot up and login for all refpolicy types.

Perfect, that's what I had when testing on my reference hardware, so I'm
happy you were able to validate those results.

> 3. With parameter selinux=1 & enforcing=1
> Some of services failed to startup when booting. But this issue also exist on
> old refpolicy version (2.20170204)

Yeah, and given the scope of this change my goal was mainly parity with
the old policy but based on a version that's 2-ish years newer.  So once
that's done I think we can reasonably work at enabling the additional
services in some structured way.

> 4. refpolicy stable version (2.20190201)
> I got an do_fetch error with refpolicy stable version.
> Seems the SRC_URI is not correct. It should be "https://github.com/
> SELinuxProject/refpolicy/releases/download/RELEASE_2_20190201/refpolicy-$
> {PV}.tar.bz2"

Thanks, good catch, I don't know how that slipped through.  Corrected on
my end, I'll update it in a bit.

-J.

> 
> 
> Regards,
> Yi

-- 
-Joe MacDonald.
:wq


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PULL] refpolicy: update to 2.20190201 and git HEAD policies (2019-04-10 10:57:14 -0400)

[Joe MacDonald]

This is a huge, long-overdue update the refpolicy.  I apologise for it
blocking the other outstanding meta-selinux patches, but I've been
trying to limit the scope of changes while this happens.  Now that this
is cleared off the slate, I'll be gathering up the other meta-selinux
patches from the list.  I'll send out a follow-up on those as they're
merged and another when I think I'm done, so if I've missed your patch,
that'll be the time to ping me about it.

As for this, here's what I've done.

- manually reviewed all patches that had been present in
  repolicy-* for both the old stable (2.20170204) and git
  versions

- forked the SELinuxPolicy/refpolicy repo and applied all
  still-relevant patches to the RELEASE_2.20190201 branch

- restructured the patches so that all patches that should
  reasonably apply to all variants (mcs, mls, minimum, standard
  and targeted) were in a common branch and only the ones that
  are specific to each variant would be in their own recipe

- restructure the patches so that systemd and sysvinit patches
  were not applied to the same tree

- created a parallel set of branches for each of these against
  current git HEAD

The results of this can be examined here:

https://github.com/joeythesaint/refpolicy

Then each of these were exported and put in the appropriate SRC_URIs so
the branch structure is more-or-less preserved.

My goals with this approach were the following:

- make it easier to keep refpolicy up to date, particularly for
  anyone wanting to use the git variants

- make it easier to determine how your preferred version of
  refpolicy on Yocto differs from upstream refpolicy

- limit the above differences to the minimum to achieve the goal
  of a functional Yocto system

- eventually move us away from release tarballs entirely

That last point is why I'm preserving the refpolicy fork above.  I'd
like to keep going with this and so future refpolicy patches will first
be put in that repo then exported and applied to the SRC_URIs.  If you
have such a patch and want to send me a PR against the branch you think
it belongs on from github directly, that'd be awesome, but the old
method of patches to the mailing list will work fine too, just know that
this is the way I'm going to try to manage this for the foreseeable
future.  Ultimately, if this proves to work well, I would like to move
the refpolicy fork off github and house it on git.yoctoproject.org
beside meta-selinux, but the workflow needs to be properly validated
first.

One additional point, I intend to take another pass at revising this
stuff, ideally moving the huge number of common patches out as well.
There's still some that aren't necessary for base yocto but are for
additional layers.  That's fine for us to have, but I'd like to get
those moved to optional layer directories so we're making the best use
of that functionality we can.  If you have suggestions on which pieces
already present are good candidates, let me know.  Similarly, if you've
got additional policy patches you want to see included, feel free to
send them along, we can easily move them to optional locations inside
meta-selinux.

Finally, please everyone test this and provide feedback on anything that
doesn't work or looks strange.  This is easily the biggest change we've
had in meta-selinux in years and I expect there's still some wrinkles to
be ironed out.  And I really appreciate everyone's patience while we got
to this point and hope it's not too much more pain before we put a
ribbon on this and call it done.

I'll give this until at least the weekend before merging it to master,
pending comments or an overwhelming "please just do it" from the
community.

Thanks.

---

The following changes since commit a6a3cadb1ef3203a123d8f5f9df27832f55b2ce3:

  Backport patches from upstream to fix build with musl (2019-03-25 09:43:53 
+0100)

are available in the Git repository at:

  git://git.yoctoproject.org/meta-selinux yocto/master-next

for you to fetch changes up to 776da889b550ac9e5be414a8cc10fd86b1923264:

  refpolicy: update to 2.20190201 and git HEAD policies (2019-04-10 10:57:14 
-0400)


Joe MacDonald (1):
  refpolicy: update to 2.20190201 and git HEAD policies

 README |  16 +-
 .../refpolicy-2.20170204/poky-fc-clock.patch   |  20 --
 .../poky-fc-corecommands.patch |  24 --
 .../refpolicy-2.20170204/poky-fc-dmesg.patch   |  18 --
 .../poky-fc-fix-real-path_login.patch  |  37 ---
 .../poky-fc-fix-real-path_shadow.patch |  34 ---
 .../refpolicy-2.20170204/poky-fc-fstool

Re: [yocto] [meta-selinux][PATCH] selinux: remove git version

[Joe MacDonald]

Hi Yi,

I'm in the process of updating a big portion of the meta-selinux layer,
starting with the policy and working outward.  I am planning to update
these packages (and likely merge this) but I'm not merging your patch
yet until everything else is sorted out.

Just wanted to follow up with you so you knew what was happening.

-J.

[[meta-selinux][PATCH] selinux: remove git version] On 19.04.02 (Tue 08:54) Yi 
Zhao wrote:

> The git version of libselinux libsemanage libsepol checkpolicy and
> policycoreutils are far behind the master branch and now they can not
> build due to the do_patch error. The current stable 2.8 version works
> well so we can remove them.
> 
> Signed-off-by: Yi Zhao 
> ---
>  recipes-security/selinux/checkpolicy_git.bb |  6 --
>  recipes-security/selinux/libselinux_git.bb  | 14 --
>  recipes-security/selinux/libsemanage_git.bb | 17 -
>  recipes-security/selinux/libsepol_git.bb|  8 
>  recipes-security/selinux/policycoreutils_git.bb |  6 --
>  recipes-security/selinux/selinux_git.inc| 11 ---
>  6 files changed, 62 deletions(-)
>  delete mode 100644 recipes-security/selinux/checkpolicy_git.bb
>  delete mode 100644 recipes-security/selinux/libselinux_git.bb
>  delete mode 100644 recipes-security/selinux/libsemanage_git.bb
>  delete mode 100644 recipes-security/selinux/libsepol_git.bb
>  delete mode 100644 recipes-security/selinux/policycoreutils_git.bb
>  delete mode 100644 recipes-security/selinux/selinux_git.inc
> 
> diff --git a/recipes-security/selinux/checkpolicy_git.bb 
> b/recipes-security/selinux/checkpolicy_git.bb
> deleted file mode 100644
> index 6d1d23a..000
> --- a/recipes-security/selinux/checkpolicy_git.bb
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -PV = "2.7+git${SRCPV}"
> -
> -include selinux_git.inc
> -include ${BPN}.inc
> -
> -LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
> diff --git a/recipes-security/selinux/libselinux_git.bb 
> b/recipes-security/selinux/libselinux_git.bb
> deleted file mode 100644
> index a43b184..000
> --- a/recipes-security/selinux/libselinux_git.bb
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -PV = "2.7+git${SRCPV}"
> -
> -include selinux_git.inc
> -include ${BPN}.inc
> -
> -LIC_FILES_CHKSUM = "file://LICENSE;md5=84b4d2c6ef954a2d4081e775a270d0d0"
> -
> -SRC_URI += "\
> - file://libselinux-drop-Wno-unused-but-set-variable.patch \
> - file://libselinux-make-O_CLOEXEC-optional.patch \
> - file://libselinux-make-SOCK_CLOEXEC-optional.patch \
> - file://libselinux-define-FD_CLOEXEC-as-necessary.patch \
> - file://0001-src-Makefile-fix-includedir-in-libselinux.pc.patch \
> - "
> diff --git a/recipes-security/selinux/libsemanage_git.bb 
> b/recipes-security/selinux/libsemanage_git.bb
> deleted file mode 100644
> index 2e1fdc8..000
> --- a/recipes-security/selinux/libsemanage_git.bb
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -PV = "2.7+git${SRCPV}"
> -
> -include selinux_git.inc
> -include ${BPN}.inc
> -
> -LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343"
> -
> -SRC_URI += "\
> - file://libsemanage-Fix-execve-segfaults-on-Ubuntu.patch \
> - file://libsemanage-fix-path-nologin.patch \
> - file://libsemanage-drop-Wno-unused-but-set-variable.patch \
> - file://libsemanage-define-FD_CLOEXEC-as-necessary.patch;striplevel=2 \
> - file://libsemanage-allow-to-disable-audit-support.patch \
> - file://libsemanage-disable-expand-check-on-policy-load.patch \
> - file://0001-src-Makefile-fix-includedir-in-libselinux.pc.patch \
> - "
> -FILES_${PN} += "/usr/libexec"
> diff --git a/recipes-security/selinux/libsepol_git.bb 
> b/recipes-security/selinux/libsepol_git.bb
> deleted file mode 100644
> index f9b8010..000
> --- a/recipes-security/selinux/libsepol_git.bb
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -PV = "2.7+git${SRCPV}"
> -
> -include selinux_git.inc
> -include ${BPN}.inc
> -
> -LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343"
> -
> -SRC_URI += "file://0001-src-Makefile-fix-includedir-in-libsepol.pc.patch"
> diff --git a/recipes-security/selinux/policycoreutils_git.bb 
> b/recipes-security/selinux/policycoreutils_git.bb
> deleted file mode 100644
> index 6d1d23a..000
> --- a/recipes-security/selinux/policycoreutils_git.bb
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -PV = "2.7+git${SRCPV}"
> -
> -include selinux_git.inc
> -include ${BPN}.inc
> -
> -LIC_FILES_CHKSUM = "file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
> diff --git a/recipes-security/selinux/selinux_git.inc 
> b/recipes-security/selinux/selinux_git.inc
> deleted file mode 100644
> index 9887bd1..000
> --- a/recipes-security/selinux/selinux_git.inc
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -SRCREV = "1bac758bf6cf884c112b80545d5fc5b668fc7d71"
> -
> -SRC_URI = "git://github.com/SELinuxProject/selinux.git;protocol=http"
> -
> -include selinux_common.inc
> -
> -# ${S} is set in selinux_common above, but w

Re: [yocto] [selinux] sumo compilation

[Joe MacDonald]

[Re: [yocto] [selinux] sumo compilation] On 18.12.30 (Sun 14:31) MacDonald, Joe 
wrote:

> I have both ready to go, there's been a few hiccups with my access to the git
> server. I'll push my queued changes somewhere public when I get to a keyboard
> later today so at least everyone can see what's coming. 

Update on this.  While we're sorting out the access issue, the current
master, sumo and thud branches on my personal mirror
(https://github.com/joeythesaint/meta-selinux) are mostly up-to-date
(the only thing I haven't included in there yet is the refpolicy update
for the 20180114 release, little overdue, that) and build for the
respective Yocto releases.  If that's not your experience, please let me
know and we'll get that sorted out right away.

Thanks.

-Joe.

> 
> -J.
> 
> On Dec 30, 2018 6:29 AM, Stefano Cappa  wrote:
> Are there any news about this? Also for thud branch. 
> 
> Il mar 30 ott 2018, 14:46 Sinan Kaya  ha scritto:
> 
> On 10/24/2018 7:49 PM, Joe MacDonald wrote:
> > Hey all,
> >
> > I just thought I should quickly follow up on this.  I have a change set
> > ready that includes tagging and a minor tweak for sumo, integration of
> > the current outstanding patch list and a tag for thud and a couple of
> > additional things (possibly) for post-thud.  I'll send out a set for
> > sumo and maybe an additional one for thud/post- possibly tomorrow or
> > after I get home on Friday.
> 
> Thanks, we are looking forward to see it on yocto.
> 
> >
> > -J.
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 

> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][sumo][PATCH 1/7] layer.conf: update LAYERSERIES_COMPAT `sumo' -> `thud'

[Joe MacDonald]

The patch set is definitely confusing.  I'm not able to access
git.yoctoproject.org at the moment, so I've pushed all three proposed
branch updates to my fork on github.  I think that's a more useful way to
review these changes anyway:

https://github.com/joeythesaint/meta-selinux/tree/jjm/master
https://github.com/joeythesaint/meta-selinux/tree/jjm/sumo
https://github.com/joeythesaint/meta-selinux/tree/jjm/thud

-J.


On Mon, Oct 29, 2018 at 3:16 PM akuster  wrote:

>
> On 10/29/18 11:32 AM, Joe MacDonald wrote:
> > From: Hongxu Jia 
> >
> > Since `9ec5a8a layer.conf: Drop sumo from LAYERSERIES_CORENAMES' and
> > `9867924 layer.conf: Add thud to LAYERSERIES_CORENAMES' applied in
> oe-core,
> > update LAYERSERIES_COMPAT `sumo' -> `thud'
>
> the subject branch and change confuse me. Shouldn't his be for "Thud"?
>
> - armin
>
> >
> > Signed-off-by: Hongxu Jia 
> > Signed-off-by: Joe MacDonald 
> > ---
> >  conf/layer.conf | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/conf/layer.conf b/conf/layer.conf
> > index 0f9ea41..5fecac6 100644
> > --- a/conf/layer.conf
> > +++ b/conf/layer.conf
> > @@ -18,7 +18,7 @@ BBFILE_PRIORITY_selinux = "5"
> >  # cause compatibility issues with other layers
> >  LAYERVERSION_selinux = "1"
> >
> > -LAYERSERIES_COMPAT_selinux = "sumo"
> > +LAYERSERIES_COMPAT_selinux = "thud"
> >
> >  LAYERDEPENDS_selinux = " \
> >  core \
>


-- 
Joe MacDonald
:wq
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][sumo][PATCH 7/7] refpolicy: fix up all refpolicy 20170224 builds for sumo

[Joe MacDonald]

Signed-off-by: Joe MacDonald 
---
 ...poky-fc-update-alternatives_sysklogd.patch | 44 ++-
 ...add-rules-for-var-log-symlink-apache.patch | 10 ++---
 ...add-rules-for-var-log-symlink-apache.patch | 27 ++--
 recipes-security/refpolicy/refpolicy_git.inc  |  2 -
 4 files changed, 51 insertions(+), 32 deletions(-)

diff --git 
a/recipes-security/refpolicy/refpolicy-2.20170204/poky-fc-update-alternatives_sysklogd.patch
 
b/recipes-security/refpolicy/refpolicy-2.20170204/poky-fc-update-alternatives_sysklogd.patch
index 2038110..e9a0464 100644
--- 
a/recipes-security/refpolicy/refpolicy-2.20170204/poky-fc-update-alternatives_sysklogd.patch
+++ 
b/recipes-security/refpolicy/refpolicy-2.20170204/poky-fc-update-alternatives_sysklogd.patch
@@ -11,13 +11,13 @@ Upstream-Status: Inappropriate [only for Poky]
 Signed-off-by: Xin Ouyang 
 Signed-off-by: Joe MacDonald 
 ---
- policy/modules/system/logging.fc |4 
- policy/modules/system/logging.te |1 +
+ policy/modules/system/logging.fc |3 +++
+ policy/modules/system/logging.te |2 ++
  2 files changed, 5 insertions(+)
 
 --- a/policy/modules/system/logging.fc
 +++ b/policy/modules/system/logging.fc
-@@ -1,22 +1,26 @@
+@@ -1,9 +1,10 @@
  /dev/log  -s  
gen_context(system_u:object_r:devlog_t,mls_systemhigh)
  
  /etc/rsyslog.conf gen_context(system_u:object_r:syslog_conf_t,s0)
@@ -26,35 +26,37 @@ Signed-off-by: Joe MacDonald 
  /etc/audit(/.*)?  
gen_context(system_u:object_r:auditd_etc_t,mls_systemhigh)
  /etc/rc\.d/init\.d/auditd --  
gen_context(system_u:object_r:auditd_initrc_exec_t,s0)
  /etc/rc\.d/init\.d/rsyslog -- 
gen_context(system_u:object_r:syslogd_initrc_exec_t,s0)
-+/etc/rc\.d/init\.d/syslog\.sysklogd --
gen_context(system_u:object_r:syslogd_initrc_exec_t,s0)
  
- /sbin/audispd --  gen_context(system_u:object_r:audisp_exec_t,s0)
- /sbin/audisp-remote   --  
gen_context(system_u:object_r:audisp_remote_exec_t,s0)
- /sbin/auditctl--  
gen_context(system_u:object_r:auditctl_exec_t,s0)
- /sbin/auditd  --  gen_context(system_u:object_r:auditd_exec_t,s0)
- /sbin/klogd   --  gen_context(system_u:object_r:klogd_exec_t,s0)
-+/sbin/klogd\.sysklogd --  gen_context(system_u:object_r:klogd_exec_t,s0)
- /sbin/minilogd--  
gen_context(system_u:object_r:syslogd_exec_t,s0)
- /sbin/rklogd  --  gen_context(system_u:object_r:klogd_exec_t,s0)
- /sbin/rsyslogd--  
gen_context(system_u:object_r:syslogd_exec_t,s0)
- /sbin/syslogd --  gen_context(system_u:object_r:syslogd_exec_t,s0)
-+/sbin/syslogd\.sysklogd   --  
gen_context(system_u:object_r:syslogd_exec_t,s0)
- /sbin/syslog-ng   --  
gen_context(system_u:object_r:syslogd_exec_t,s0)
+ /usr/bin/audispd  --  gen_context(system_u:object_r:audisp_exec_t,s0)
+@@ -27,14 +28,16 @@
+ /usr/sbin/audispd --  gen_context(system_u:object_r:audisp_exec_t,s0)
+ /usr/sbin/audisp-remote   --  
gen_context(system_u:object_r:audisp_remote_exec_t,s0)
+ /usr/sbin/auditctl--  
gen_context(system_u:object_r:auditctl_exec_t,s0)
+ /usr/sbin/auditd  --  gen_context(system_u:object_r:auditd_exec_t,s0)
+ /usr/sbin/klogd   --  
gen_context(system_u:object_r:klogd_exec_t,s0)
++/usr/sbin/klogd\.sysklogd --  
gen_context(system_u:object_r:klogd_exec_t,s0)
+ /usr/sbin/metalog --  gen_context(system_u:object_r:syslogd_exec_t,s0)
+ /usr/sbin/minilogd--  gen_context(system_u:object_r:syslogd_exec_t,s0)
+ /usr/sbin/rklogd  --  gen_context(system_u:object_r:klogd_exec_t,s0)
+ /usr/sbin/rsyslogd--  gen_context(system_u:object_r:syslogd_exec_t,s0)
++/usr/sbin/syslogd\.sysklogd   --  
gen_context(system_u:object_r:syslogd_exec_t,s0)
+ /usr/sbin/syslog-ng   --  gen_context(system_u:object_r:syslogd_exec_t,s0)
+ /usr/sbin/syslogd --  gen_context(system_u:object_r:syslogd_exec_t,s0)
  
- /usr/lib/systemd/system/auditd.* -- 
gen_context(system_u:object_r:auditd_unit_t,s0)
- /usr/lib/systemd/system/[^/]*systemd-journal.* -- 
gen_context(system_u:object_r:syslogd_unit_t,s0)
- /usr/lib/systemd/systemd-journald -- 
gen_context(system_u:object_r:syslogd_exec_t,s0)
+ /var/lib/misc/syslog-ng.persist-? -- 
gen_context(system_u:object_r:syslogd_var_lib_t,s0)
+ /var/lib/syslog-ng(/.*)?  
gen_context(system_u:object_r:syslogd_var_lib_t,s0)
 --- a/policy/modules/system/logging.te
 +++ b/policy/modules/system/logging.te
-@@ -388,10 +388,11 @@ allow syslogd_t self:unix_dgram_socket s
+@@ -390,10 +390,12 @@ allow syslogd_t self:unix_dgram_socket s
  allow syslogd_t self:fifo_file rw_fifo_file_perms;
  allow syslogd_t self:udp_socket create_socket_perms;
  allow syslogd_t self:tcp_socket create_stream_socket_perms;
  
  allow syslogd_t syslog_conf_t:file read_file_perms;
 +allow syslogd_t syslog_conf_t:lnk_file read_file_perms;
++allow

[yocto] [meta-selinux][sumo][PATCH 5/7] refpolicy_git.inc: lock SRCREVs on the actual version hashes

[Joe MacDonald]

From: Awais Belal 

Using AUTOREV in the main repository has its downsides.
1. The checked out version isn't actually the version depicted
   by PV.
2. Breaks builds in scenarios where network isn't available
   or BB_NO_NETWORK is used even after sources are already
   fetched.

1 is self explanatory, for 2 whenever SRCREV is set to AUTOREV and
SRCPV is used in PV the fetcher tries to access the network in order
to determine SRCPV (bb.fetch2.get_srcrev) and fails for obvious
reasons during parsing even when versioned recipes are used as
PREFERRED_VERSION because parsing still happens for recipes that are
in BB's search paths and we see.
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was 
${@bb.fetch2.get_srcrev(d)} which triggered exception NetworkAccess: Network 
access disabled through BB_NO_NETWORK (or set indirectly due to use of 
BB_FETCH_PREMIRRORONLY) but access requested with command git -c 
core.fsyncobjectfiles=0 ls-remote 
git://github.com/TresysTechnology/refpolicy.git  (for url 
git://github.com/TresysTechnology/refpolicy.git)

So we lock the REVs and do that with a soft assignment which
allows overriding the REVs from elsewhere.

Signed-off-by: Awais Belal 
Signed-off-by: Joe MacDonald 
---
 recipes-security/refpolicy/refpolicy_git.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-security/refpolicy/refpolicy_git.inc 
b/recipes-security/refpolicy/refpolicy_git.inc
index f71eb35..6c318ab 100644
--- a/recipes-security/refpolicy/refpolicy_git.inc
+++ b/recipes-security/refpolicy/refpolicy_git.inc
@@ -3,8 +3,8 @@ PV = "2.20170805+git${SRCPV}"
 SRC_URI = 
"git://github.com/TresysTechnology/refpolicy.git;protocol=git;branch=master;name=refpolicy;destsuffix=refpolicy"
 SRC_URI += 
"git://github.com/TresysTechnology/refpolicy-contrib.git;protocol=git;branch=master;name=refpolicy-contrib;destsuffix=refpolicy/policy/modules/contrib"
 
-SRCREV_refpolicy = "${AUTOREV}"
-SRCREV_refpolicy-contrib = "${AUTOREV}"
+SRCREV_refpolicy ?= "794ed7efd0eca19d0353659a1ec9d4ef4e4b751c"
+SRCREV_refpolicy-contrib ?= "a393275a6ecb76311323726a029767a3a01e109e"
 SRCREV_FORMAT = "refpolicy.refpolicy-contrib"
 
 FILESEXTRAPATHS_prepend := "${THISDIR}/refpolicy-git:"
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][sumo][PATCH 6/7] Revert "layer.conf: update LAYERSERIES_COMPAT `sumo' -> `thud'"

[Joe MacDonald]

This reverts commit 8ff95d5b2a693aeb4e791aacf83d24313ce35f3e.

Signed-off-by: Joe MacDonald 
---
 conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 5fecac6..0f9ea41 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -18,7 +18,7 @@ BBFILE_PRIORITY_selinux = "5"
 # cause compatibility issues with other layers
 LAYERVERSION_selinux = "1"
 
-LAYERSERIES_COMPAT_selinux = "thud"
+LAYERSERIES_COMPAT_selinux = "sumo"
 
 LAYERDEPENDS_selinux = " \
 core \
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][sumo][PATCH 3/7] libselinux: Fix build with musl libc.

[Joe MacDonald]

From: Piotr Tworek 

Musl libc does not implement file traversal functions from fts.h.
Oe-core provides fts library which implements those. Libselinux makefile
allows us to use such additional library by specifying required linker
flags via FTS_LDLIBS variable.

Signed-off-by: Piotr Tworek 
Signed-off-by: Joe MacDonald 
---
 recipes-security/selinux/libselinux.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-security/selinux/libselinux.inc 
b/recipes-security/selinux/libselinux.inc
index 28c437f..33621cc 100644
--- a/recipes-security/selinux/libselinux.inc
+++ b/recipes-security/selinux/libselinux.inc
@@ -8,6 +8,7 @@ LICENSE = "PD"
 inherit lib_package pythonnative
 
 DEPENDS += "libsepol python libpcre swig-native"
+DEPENDS_append_libc-musl = " fts"
 RDEPENDS_${PN}-python += "python-core"
 
 PACKAGES += "${PN}-python"
@@ -23,6 +24,7 @@ def get_policyconfigarch(d):
 EXTRA_OEMAKE += "${@get_policyconfigarch(d)}"
 
 EXTRA_OEMAKE += "LDFLAGS='${LDFLAGS} -lpcre' 
LIBSEPOLA='${STAGING_LIBDIR}/libsepol.a'"
+EXTRA_OEMAKE_append_libc-musl = " FTS_LDLIBS=-lfts"
 
 do_compile_append() {
 oe_runmake pywrap -j1 \
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][sumo][PATCH 4/7] libpcre_selinux.inc: fix do_install failure if .so file does not exist

[Joe MacDonald]

From: Chen Qi 

In case of the existence of meta-mingw, the library is .dll instead of
.so and these .dll files are in ${bindir}.

We need to check the existence of the .so file before doing readlink,
otherwise do_install fails.

Signed-off-by: Chen Qi 
Signed-off-by: Joe MacDonald 
---
 recipes-support/libpcre/libpcre_selinux.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-support/libpcre/libpcre_selinux.inc 
b/recipes-support/libpcre/libpcre_selinux.inc
index 59c0184..d886792 100644
--- a/recipes-support/libpcre/libpcre_selinux.inc
+++ b/recipes-support/libpcre/libpcre_selinux.inc
@@ -1,5 +1,5 @@
 do_install_append () {
-   if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
+   if [ ! ${D}${libdir} -ef ${D}${base_libdir} -a -e 
${D}${libdir}/libpcre.so ]; then
realsofile=`readlink ${D}${libdir}/libpcre.so`
mkdir -p ${D}/${base_libdir}/
mv -f ${D}${libdir}/libpcre.so.* ${D}${base_libdir}/
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][sumo][PATCH 2/7] setools: Add missing python runtime deps.

[Joe MacDonald]

From: Piotr Tworek 

The package needs logging, json and argparse modules to start.
Additionaly, it also needs libselinux-python in order to really work.
Without it it'll just print an error message instructing the user to
install it.

Signed-off-by: Piotr Tworek 
Signed-off-by: Joe MacDonald 
---
 recipes-security/setools/setools_4.1.1.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-security/setools/setools_4.1.1.bb 
b/recipes-security/setools/setools_4.1.1.bb
index 5b6d47d..c5a2d34 100644
--- a/recipes-security/setools/setools_4.1.1.bb
+++ b/recipes-security/setools/setools_4.1.1.bb
@@ -23,7 +23,8 @@ LIC_FILES_CHKSUM = 
"file://${S}/COPYING;md5=83a5eb6974c11f30785e90d0eeccf40c \
 
 DEPENDS += "bison-native flex-native swig-native python libsepol"
 
-RDEPENDS_${PN} += "python-networkx python-enum34 python-decorator 
python-setuptools"
+RDEPENDS_${PN} += "python-networkx python-enum34 python-decorator 
python-setuptools \
+   python-logging python-json python-argparse 
libselinux-python"
 
 RPROVIDES_${PN} += "${PN}-console"
 
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][sumo][PATCH 1/7] layer.conf: update LAYERSERIES_COMPAT `sumo' -> `thud'

[Joe MacDonald]

From: Hongxu Jia 

Since `9ec5a8a layer.conf: Drop sumo from LAYERSERIES_CORENAMES' and
`9867924 layer.conf: Add thud to LAYERSERIES_CORENAMES' applied in oe-core,
update LAYERSERIES_COMPAT `sumo' -> `thud'

Signed-off-by: Hongxu Jia 
Signed-off-by: Joe MacDonald 
---
 conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 0f9ea41..5fecac6 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -18,7 +18,7 @@ BBFILE_PRIORITY_selinux = "5"
 # cause compatibility issues with other layers
 LAYERVERSION_selinux = "1"
 
-LAYERSERIES_COMPAT_selinux = "sumo"
+LAYERSERIES_COMPAT_selinux = "thud"
 
 LAYERDEPENDS_selinux = " \
 core \
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][sumo][PATCH 0/7] Refpolicy updates for sumo

[Joe MacDonald]

I'm sending this out  as a follow-up to our discussion from last week. This
set will be placed on the newly-created 'sumo' branch.  I plan to follow up
with a slightly different version for a new 'thud' branch as well, at which
point things should be stable enough on those two branches that I can
finish up the refpolicy update (2.20180701) I'd started a little while
ago.  After that, I think top of my list is to clean up some (I think
unintended) behaviour in the _git recipe variants.

Comments / suggestions / etc. more than welcome.

-- 
Joe MacDonald
:wq
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [selinux] sumo compilation

[Joe MacDonald]

Hey all,

I just thought I should quickly follow up on this.  I have a change set
ready that includes tagging and a minor tweak for sumo, integration of
the current outstanding patch list and a tag for thud and a couple of
additional things (possibly) for post-thud.  I'll send out a set for
sumo and maybe an additional one for thud/post- possibly tomorrow or
after I get home on Friday.

-J.

[Re: [yocto] [selinux] sumo compilation] On 18.10.18 (Thu 15:08) Joe MacDonald 
wrote:

> [Re: [yocto] [selinux] sumo compilation] On 18.10.18 (Thu 11:00) Mark Hatle 
> wrote:
> 
> > On 10/18/18 9:49 AM, Sinan Kaya wrote:
> > > CC'ing the selinux maintainers:
> > > 
> > > I was told that using the master branch and reverting the e2fs change
> > > (http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=78eca8242ea5397c4dc0654d62244453b4260151)
> > >  
> > > works on sumo.
> > > 
> > > Stefano's suggestion unfortunately didn't work.
> > > 
> > > Maybe, it is time to create the sumo branch?
> > 
> > Sorry, I thought it had been created.  I'm going to be traveling the
> > next few days to ELC-E, but I will try to get to it if someone else
> > does not first.
> 
> Yeah, Mark and I are both going to be at ELC-E this week, we'll get it
> sorted out.
> 
> -J.
> 
> > 
> > --Mark
> > 
> > > On 10/18/2018 9:48 AM, Steve Scott wrote:
> > >> I did not try it on sumo.
> > >>
> > >>   
> > >>
> > >> From: Stefano Cappa [mailto:stefano.cappa.k...@gmail.com]
> > >> Sent: Wednesday, October 17, 2018 11:15 PM
> > >> To: ssc...@san.rr.com
> > >> Cc: Sinan Kaya ; yocto@yoctoproject.org
> > >> Subject: Re: [yocto] [selinux] sumo compilation
> > >>
> > >>   
> > >>
> > >> Exactly the same issue since September.
> > >>
> > >>   
> > >>
> > >> Here is my discussion 
> > >> https://lists.yoctoproject.org/pipermail/yocto/2018-September/042711.html.
> > >>  With that trick did you find a solution also on sumo?
> > >>
> > >>   
> > >>
> > >> Il gio 18 ott 2018, 01:42 mailto:ssc...@san.rr.com> 
> > >> > ha scritto:
> > >>
> > >>
> > >> It was broken in rocko too. I added this to local.conf to workaround the 
> > >> problem:
> > >>
> > >> PREFERRED_VERSION_refpolicy-standard = "2.20170204"
> > >>
> > >> -steve
> > >>
> > >>  Sinan Kaya mailto:ok...@kernel.org> > wrote:
> > >>> Hi,
> > >>>
> > >>> We realized today that SELinux does not compile on sumo branch.
> > >>>
> > >>> Is it possible for someone to branch the last working version to a sumo 
> > >>> branch?
> > >>>
> > >>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/refs/
> > >>>
> > >>> NOTE: Running task 352 of 2707
> > >>> (virtual:native:/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb
> > >>>  <http://e2fsprogs_1.43.8.bb> :do_patch)
> > >>> NOTE: recipe e2fsprogs-native-1.43.8-r0: task do_patch: Started
> > >>> NOTE: Running task 1413 of 2707
> > >>> (/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb:do_patch)
> > >>> NOTE: recipe e2fsprogs-1.43.8-r0: task do_patch: Started
> > >>> ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt 
> > >>> --quiltrc
> > >>> Applying patch misc_create_inode.c-label_rootfs.patch
> > >>> patching file misc/create_inode.c
> > >>> Hunk #1 FAILED at 979.
> > >>> Hunk #2 FAILED at 987.
> > >>>
> > >>> Sinan
> > >>> -- 
> > >>> ___
> > >>> yocto mailing list
> > >>> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> > >>> https://lists.yoctoproject.org/listinfo/yocto
> > >>
> > > 
> > 



> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [selinux] sumo compilation

[Joe MacDonald]

[Re: [yocto] [selinux] sumo compilation] On 18.10.18 (Thu 11:00) Mark Hatle 
wrote:

> On 10/18/18 9:49 AM, Sinan Kaya wrote:
> > CC'ing the selinux maintainers:
> > 
> > I was told that using the master branch and reverting the e2fs change
> > (http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=78eca8242ea5397c4dc0654d62244453b4260151)
> >  
> > works on sumo.
> > 
> > Stefano's suggestion unfortunately didn't work.
> > 
> > Maybe, it is time to create the sumo branch?
> 
> Sorry, I thought it had been created.  I'm going to be traveling the
> next few days to ELC-E, but I will try to get to it if someone else
> does not first.

Yeah, Mark and I are both going to be at ELC-E this week, we'll get it
sorted out.

-J.

> 
> --Mark
> 
> > On 10/18/2018 9:48 AM, Steve Scott wrote:
> >> I did not try it on sumo.
> >>
> >>   
> >>
> >> From: Stefano Cappa [mailto:stefano.cappa.k...@gmail.com]
> >> Sent: Wednesday, October 17, 2018 11:15 PM
> >> To: ssc...@san.rr.com
> >> Cc: Sinan Kaya ; yocto@yoctoproject.org
> >> Subject: Re: [yocto] [selinux] sumo compilation
> >>
> >>   
> >>
> >> Exactly the same issue since September.
> >>
> >>   
> >>
> >> Here is my discussion 
> >> https://lists.yoctoproject.org/pipermail/yocto/2018-September/042711.html. 
> >> With that trick did you find a solution also on sumo?
> >>
> >>   
> >>
> >> Il gio 18 ott 2018, 01:42 mailto:ssc...@san.rr.com> > 
> >> ha scritto:
> >>
> >>
> >> It was broken in rocko too. I added this to local.conf to workaround the 
> >> problem:
> >>
> >> PREFERRED_VERSION_refpolicy-standard = "2.20170204"
> >>
> >> -steve
> >>
> >>  Sinan Kaya mailto:ok...@kernel.org> > wrote:
> >>> Hi,
> >>>
> >>> We realized today that SELinux does not compile on sumo branch.
> >>>
> >>> Is it possible for someone to branch the last working version to a sumo 
> >>> branch?
> >>>
> >>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/refs/
> >>>
> >>> NOTE: Running task 352 of 2707
> >>> (virtual:native:/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb
> >>>   :do_patch)
> >>> NOTE: recipe e2fsprogs-native-1.43.8-r0: task do_patch: Started
> >>> NOTE: Running task 1413 of 2707
> >>> (/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb:do_patch)
> >>> NOTE: recipe e2fsprogs-1.43.8-r0: task do_patch: Started
> >>> ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt 
> >>> --quiltrc
> >>> Applying patch misc_create_inode.c-label_rootfs.patch
> >>> patching file misc/create_inode.c
> >>> Hunk #1 FAILED at 979.
> >>> Hunk #2 FAILED at 987.
> >>>
> >>> Sinan
> >>> -- 
> >>> ___
> >>> yocto mailing list
> >>> yocto@yoctoproject.org 
> >>> https://lists.yoctoproject.org/listinfo/yocto
> >>
> > 
> 


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] policycorutils: package files in base_sbindir.

[Joe MacDonald]

Merged, thanks Eric.  Unfortunate oversight from a last minute change to
handle some other changes around policycorutils.

-J.

[[yocto] [meta-selinux][PATCH] policycorutils: package files in base_sbindir.] 
On 18.09.09 (Sun 19:25) Eric Chanudet wrote:

> SBINDIR was changed to ${base_sbindir} in commit:
> 8cc9c17 policycoreutils: fix installed-but-not-shipped on updated recipes
> 
> FILES_${PN}-* must now capture files installed in ${base_sbindir}
> accordingly.
> 
> Signed-off-by: Eric Chanudet 
> ---
>  recipes-security/selinux/policycoreutils.inc | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/recipes-security/selinux/policycoreutils.inc 
> b/recipes-security/selinux/policycoreutils.inc
> index 98000de..85ff164 100644
> --- a/recipes-security/selinux/policycoreutils.inc
> +++ b/recipes-security/selinux/policycoreutils.inc
> @@ -79,26 +79,25 @@ PACKAGES =+ "\
>   ${PN}-setsebool \
>  "
>  FILES_${PN}-fixfiles += "${base_sbindir}/fixfiles"
> -FILES_${PN}-genhomedircon += "${sbindir}/genhomedircon"
> +FILES_${PN}-genhomedircon += "${base_sbindir}/genhomedircon"
>  FILES_${PN}-loadpolicy += "\
>   ${base_sbindir}/load_policy \
> - ${sbindir}/load_policy \
>  "
>  FILES_${PN}-newrole += "\
>   ${bindir}/newrole \
>   ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 
> '${sysconfdir}/pam.d/newrole', '', d)} \
>  "
>  FILES_${PN}-runinit += "\
> - ${sbindir}/run_init \
> - ${sbindir}/open_init_pty \
> + ${base_sbindir}/run_init \
> + ${base_sbindir}/open_init_pty \
>   ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 
> '${sysconfdir}/pam.d/run_init', '', d)} \
>  "
>  FILES_${PN}-dbg += "${prefix}/libexec/selinux/hll/.debug"
>  FILES_${PN}-secon += "${bindir}/secon"
> -FILES_${PN}-semodule += "${sbindir}/semodule"
> +FILES_${PN}-semodule += "${base_sbindir}/semodule"
>  FILES_${PN}-hll += "${prefix}/libexec/selinux/hll/*"
>  FILES_${PN}-sestatus += "\
> - ${sbindir}/sestatus \
> + ${base_sbindir}/sestatus \
>   ${sysconfdir}/sestatus.conf \
>  "
>  FILES_${PN}-setfiles += "\
> @@ -106,7 +105,7 @@ FILES_${PN}-setfiles += "\
>   ${base_sbindir}/setfiles \
>  "
>  FILES_${PN}-setsebool += "\
> - ${sbindir}/setsebool \
> + ${base_sbindir}/setsebool \
>   ${datadir}/bash-completion/completions/setsebool \
>  "
>  
> -- 
> 2.18.0
-- 
-Joe MacDonald.
:wq
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux] master branch updates

[Joe MacDonald]

Hi all,

Just a quick update on meta-selinux since we don't have a patchworks I
can point anyone to for checking the status of their patches.

I've merged 9 commits from the past couple of months that appear to be
functional changes and that restore building status (for at least an
selinux-enabled core-image-minimal and core-image-sato on x86_64).
There were a number of additional patches that appeared to be cleanup in
nature which did not apply to any version of master I was able to
quickly identify, so I'm leaving those aside.  I suspect there were also
some patches that did not get a [meta-selinux] tag in the subject line
for the mailing list.

If you don't see your patch in the tree now and you think we still need
it, please send it out again, ensuring you get [meta-selinux] in the
subject so there's no chance it gets missed by my mail filters.

I'm aware of build and boot issues on arm and arm64, I'm looking at
getting that functional now, but if you've got changes to support those
that have presumably fallen through the cracks, please feel free to send
them again or point me at them in the archives.

Thanks.

-- 
-Joe MacDonald.
:wq
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] libselinux: python-importlib is now part of python*-core

[Joe MacDonald]

, so my understand was that audit
> >> itself was moving into core during the sumo time frame (if it hadn't 
> >> already
> >> been oved.)
> >>
> >> I don't know anything about meson, so I can't speak to that...
> >>
> >>> Further, refpolicy_git does not build anymore as the YP specific patches
> >>> do not apply anymore since upstream changed.
> >> The refpolicy is and has always been crap.  I've been talking to a few 
> >> people on
> >> IRC about working to replace the refpolicy with a policy that can be 
> >> generated
> >> dynamically based on the contents of the recipes.  I don't know if that is
> >> really going to happen, but I hate the way it's currently implemented.
> >>
> >> One of the key issues about the refpolicy is that you need to be an expert 
> >> at
> >> this (which I never claimed to be) in order to make any reasonable 
> >> decision --
> >> add to that any specific policy needs to userstand overall system design, 
> >> and I
> >> wouldn't trust any of the refpolicy items as they stand in meta-selinux.
> >>
> >> --Mark
> >>
> >>> Thanks,
> >>> Rudi
> >>>
> >>>
> >>>
> >>> On 05/07/2018 10:20 AM, akuster808 wrote:
> >>>> On 04/14/2018 07:08 PM, Armin Kuster wrote:
> >>>>> Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 
> >>>>> 'restorecond', 'libselinux', 'python-importlib']
> >>>>>
> >>>>> Signed-off-by: Armin Kuster 
> >>>> ping
> >>>>> ---
> >>>>>  recipes-security/selinux/libselinux.inc | 2 +-
> >>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/recipes-security/selinux/libselinux.inc 
> >>>>> b/recipes-security/selinux/libselinux.inc
> >>>>> index bd5ce8d..51d0875 100644
> >>>>> --- a/recipes-security/selinux/libselinux.inc
> >>>>> +++ b/recipes-security/selinux/libselinux.inc
> >>>>> @@ -8,7 +8,7 @@ LICENSE = "PD"
> >>>>>  inherit lib_package pythonnative
> >>>>>  
> >>>>>  DEPENDS += "libsepol python libpcre swig-native"
> >>>>> -RDEPENDS_${PN}-python += "python-importlib"
> >>>>> +RDEPENDS_${PN}-python += "python-core"
> >>>>>  
> >>>>>  PACKAGES += "${PN}-python"
> >>>>>  FILES_${PN}-python = 
> >>>>> "${libdir}/python${PYTHON_BASEVERSION}/site-packages/*"
> >>>
> >>>
> > 
> 
> 




-- 
-Joe MacDonald.
:wq


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] libselinux: python-importlib is now part of python*-core

[Joe MacDonald]

[Re: [yocto] [meta-selinux][PATCH] libselinux: python-importlib is now part of 
python*-core] On 18.05.07 (Mon 10:20) akuster808 wrote:

> 
> 
> On 04/14/2018 07:08 PM, Armin Kuster wrote:
> > Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 
> > 'restorecond', 'libselinux', 'python-importlib']
> >
> > Signed-off-by: Armin Kuster 
> ping

Hey all,

I'm working through selinux issues now.

-J.

> > ---
> >  recipes-security/selinux/libselinux.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/recipes-security/selinux/libselinux.inc 
> > b/recipes-security/selinux/libselinux.inc
> > index bd5ce8d..51d0875 100644
> > --- a/recipes-security/selinux/libselinux.inc
> > +++ b/recipes-security/selinux/libselinux.inc
> > @@ -8,7 +8,7 @@ LICENSE = "PD"
> >  inherit lib_package pythonnative
> >  
> >  DEPENDS += "libsepol python libpcre swig-native"
> > -RDEPENDS_${PN}-python += "python-importlib"
> > +RDEPENDS_${PN}-python += "python-core"
> >  
> >  PACKAGES += "${PN}-python"
> >  FILES_${PN}-python = 
> > "${libdir}/python${PYTHON_BASEVERSION}/site-packages/*"
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SELinux with Busybox on morty

[Joe MacDonald]

Hi Justin / Marco,

[Re: SELinux with Busybox on morty] On 17.07.19 (Wed 16:05) Justin Clacherty 
wrote:

> Hi Joe,
> 
> Is this something you or one of the other meta-selinux devs are able
> to help out with or is it more of an upstream question?

I'll see if I can give this a shot.  :-)

> 
> Cheers,
> Justin.
> 
> 
> > On 17 Jul 2017, at 4:57 pm, Marco Ostini  wrote:
> > 
> > 
> > Hi All,
> > 
> > At the moment I'm attempting to prepare a VM of morty with SELinux
> > running well in enforcing mode. Once bedded down this will be
> > running on an embedded system.
> > 
> > We use Busybox to keep the environment slim.
> > 
> > As you may be aware the file contexts of
> > /etc/selinux/targeted/contexts/files/file_contexts don't include
> > appropriate paths (/sbin + /usr/lib/busybox/sbin/) and relative file
> > contexts for commands provided by Busybox. The /sbin files provided
> > by Busybox are symlinks to their counterparts in
> > /usr/lib/busybox/sbin/.
> > 
> > I've attempted to use semanage to apply file contexts and look up
> > login contexts. Any time I use semanage I receive this message:
> > 
> >Error: Failed to read //etc/selinux/targeted/policy/policy.30 policy file
> > 
> > In an attempt to mitigate this error I ran semodule --build and
> > while it did rebuild the policy file, it didn't mitigate the error
> > message generated by semanage. At the moment I'm applying temporary
> > file contexts with chcon.
> > 
> > My questions are:
> > 
> > 1. Is it possible to run Busybox (providing init, getty, syslog ...)
> > in SELinux enforcing. If so, where's the policy files?

You haven't mentioned which policy you're currently using so I'm
guessing it is the default you get from meta-selinux, that is
refpolicy-git.  I've been debugging some (I think) unrelated issues with
refpolicy-git this week, so my advice would first to be try out
2.20151208, the current release version we have in tree.  That's
obviously also out of date, but it is currently better tested than the
git recipe.

All that said, yes, we have been, in the past, able to use busybox with
SELinux enforcing enabled, though as you can see from the layer, we've
had to tweak refpolicy to make it work well.  I'm adding a colleague of
mine here, Shrikant, who has done a fair bit of recent work with
meta-selinux as well, he might have some additional insight into the
current status of busybox-based systems.

> > 2. Is there some documentation somewhere on reference builds of
> > Morty with SELinux enforcing ?

There is not at the moment, as far as I know.  It's possible that
someone else currently using that combination can help out with some
guidance, but we haven't done any Morty+SELinux specific documentation.
Since I'm investigating some other issues right now in a slightly
different area, though, I may get some time next week to write up
something quick for this for you, though. If I do, I'll be sure to share
it here.

-- 
-Joe MacDonald.
:wq


signature.asc
Description: PGP signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] systemd: no need to inherit enable-selinux

[Joe MacDonald]

[RE: [yocto] [meta-selinux][PATCH] systemd: no need to inherit enable-selinux] 
On 17.05.08 (Mon 01:40) Huang, Jie (Jackie) wrote:

> 
> 
> > -Original Message-
> > From: Joe MacDonald [mailto:joe_macdon...@mentor.com]
> > Sent: Tuesday, May 02, 2017 21:14
> > To: Huang, Jie (Jackie)
> > Cc: yocto@yoctoproject.org
> > Subject: Re: [yocto] [meta-selinux][PATCH] systemd: no need to inherit 
> > enable-
> > selinux
> > 
> > [[yocto] [meta-selinux][PATCH] systemd: no need to inherit enable-selinux] 
> > On
> > 17.02.22 (Wed 14:44) jackie.hu...@windriver.com wrote:
> > 
> > > From: Jackie Huang 
> > >
> > > The selinux PACKAGECONFIG is properly handled in
> > > the recipe in oe-core, no need to inherit the
> > > enable-selinux bbclass.
> > 
> > That might be true, but other than belt-and-suspenders, what's the
> > harm in this being in the recipe?  I don't necessarily think it's an
> > invalid change but my quick count shows ~44 instances of 'inherit
> > enable-selinux' and 'inherit with-selinux' in meta-selinux, why's this
> > one significant?
> 
> That's because I have a patch to change the PACKAGECONFIG for selinux
> in oe-core to fix a dependency issue:
> 
> -PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,libselinux"
> +PACKAGECONFIG[selinux] = 
> "--enable-selinux,--disable-selinux,libselinux,initscripts-sushell"
> 
> But it would be overrode by the one in enable-selinux.bbclass:
> $ grep PACKAGECONFIG enable-selinux.bbclass
> PACKAGECONFIG_append = " ${@target_selinux(d)}"
> PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,libselinux,"
> 
> So I need to remove the inherit here in meta-selinux.

Sorry, this fell between the cracks.

So, let me make sure I understand what you're saying.  This oe-core
commit:

commit 1881c5e0c426a193630e5eed5b629b69ff3741d5
Author: Kai Kang 
Date:   Wed Jul 8 14:26:01 2015 +0800

systemd: add PACKAGECONFIG selinux

Add PACKAGECONFIG 'selinux' for systemd. debug-shell.service starts
different shell according whether selinux is enabled.

(From OE-Core rev: 3d1aa27191fe4c21428eaf4ae036acb1496b7df7)

Signed-off-by: Kai Kang 
Signed-off-by: Richard Purdie 

conflicts with the --enable/--disable settings in meta-selinux and  you
want to remove the setting in meta-selinux?  Again, I don't specifically
object to this, but I'd like to understand the why of it.  Is there a
valid scenario to include meta-selinux in your project but have selinux
disabled?  If so, I would think the settings in meta-selinux should
still take precedence.  Otherwise, I'm confused why the other 40-ish
cases aren't also covered.  I haven't investigated, but are all the
others in non-oe-core layers, maybe?

Thanks,
-J.

> 
> Thanks,
> Jackie
> 
> > 
> > -J.
> > 
> > >
> > > Signed-off-by: Jackie Huang 
> > > ---
> > >  recipes-core/systemd/systemd_%.bbappend | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/recipes-core/systemd/systemd_%.bbappend b/recipes-
> > core/systemd/systemd_%.bbappend
> > > index 8d9029b..f1bdaf8 100644
> > > --- a/recipes-core/systemd/systemd_%.bbappend
> > > +++ b/recipes-core/systemd/systemd_%.bbappend
> > > @@ -1,2 +1 @@
> > >  inherit enable-audit
> > > -inherit enable-selinux
> > > --
> > > 2.8.3
> > >
> > --
> > -Joe MacDonald.
> > :wq

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH V5] rpm: modify the rpm bbappend file to suitable for rpm4

[Joe MacDonald]

[[meta-selinux][PATCH V5] rpm: modify the rpm bbappend file to suitable for 
rpm4] On 17.05.10 (Wed 21:48) Dengke Du wrote:

> Changed in V5:
>   Let the subject more clear.
> 
> Changed in V4:
>   Make the comments more clear.
> Changed in V3:
>   Rebase the patch on the latest master branch.
> 
> Delete the does not exist files when run task do_package.
> 
> Signed-off-by: Dengke Du 
> ---
>  recipes-devtools/rpm/rpm_%.bbappend | 4 
>  1 file changed, 4 deletions(-)

I'll merge this and modify the commit log myself, but please note this
still isn't what I was asking for in the attached.  All of the "Changed
in..." lines should be after the --- line in your email.

-J.

> 
> diff --git a/recipes-devtools/rpm/rpm_%.bbappend 
> b/recipes-devtools/rpm/rpm_%.bbappend
> index 199a7e4..9f3ec90 100644
> --- a/recipes-devtools/rpm/rpm_%.bbappend
> +++ b/recipes-devtools/rpm/rpm_%.bbappend
> @@ -1,8 +1,4 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>  
> -FILES_${PN} += "${libdir}/rpm/bin/spooktool \
> -${libdir}/rpm/bin/semodule \
> -   "
> -
>  inherit with-selinux
>  PACKAGECONFIG[selinux] = "${WITH_SELINUX},${WITHOUT_SELINUX},libsemanage,"
-- 
-Joe MacDonald.
:wq
--- Begin Message ---
[[yocto] [meta-selinux][PATCH V3] rpm: modify the rpm bbappend file to suitable 
for rpm4] On 17.05.10 (Wed 03:03) Dengke Du wrote:

> Changed in V3:
>   rebase the patch on the latest master branch.
> 
> 1. change the rpm_5.4.16.bbappend to rpm_git.bbappend, this is
>because the rpm in oe-core has become rpm4 from rpm5.
> 
> 2. drop the patch for rpm5.
> 
> 3. delete the does not exist files when run task do_package.
> 
> Signed-off-by: Dengke Du 
> ---
>  recipes-devtools/rpm/{rpm_%.bbappend => rpm_git.bbappend} | 4 
>  1 file changed, 4 deletions(-)
>  rename recipes-devtools/rpm/{rpm_%.bbappend => rpm_git.bbappend} (56%)

I think I understand what you're looking to do here, but the comments
are completely unclear.  A commit log should look something like:

   rpm: move rpm recipe to rpm_git

   

   Signed-off-by: Dengke Du 
   ---
   

You can accomplish this with the --annotate flag to git-send-email and
then in your editor just ensure the revision history and additional
commentary goes after the --- line.

As for the change, deleting package contents that are no longer present
is fine, but why change % to git in the recipe name?  We moved from a
specific version number to % so we would be somewhat divorced from the
changes in oe-core, this change reverses that decision.

-J.

> diff --git a/recipes-devtools/rpm/rpm_%.bbappend 
> b/recipes-devtools/rpm/rpm_git.bbappend
> similarity index 56%
> rename from recipes-devtools/rpm/rpm_%.bbappend
> rename to recipes-devtools/rpm/rpm_git.bbappend
> index 199a7e4..9f3ec90 100644
> --- a/recipes-devtools/rpm/rpm_%.bbappend
> +++ b/recipes-devtools/rpm/rpm_git.bbappend
> @@ -1,8 +1,4 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>  
> -FILES_${PN} += "${libdir}/rpm/bin/spooktool \
> -${libdir}/rpm/bin/semodule \
> -   "
> -
>  inherit with-selinux
>  PACKAGECONFIG[selinux] = "${WITH_SELINUX},${WITHOUT_SELINUX},libsemanage,"
> -- 
> 2.11.0
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
--- End Message ---


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH V3] rpm: modify the rpm bbappend file to suitable for rpm4

[Joe MacDonald]

[[yocto] [meta-selinux][PATCH V3] rpm: modify the rpm bbappend file to suitable 
for rpm4] On 17.05.10 (Wed 03:03) Dengke Du wrote:

> Changed in V3:
>   rebase the patch on the latest master branch.
> 
> 1. change the rpm_5.4.16.bbappend to rpm_git.bbappend, this is
>because the rpm in oe-core has become rpm4 from rpm5.
> 
> 2. drop the patch for rpm5.
> 
> 3. delete the does not exist files when run task do_package.
> 
> Signed-off-by: Dengke Du 
> ---
>  recipes-devtools/rpm/{rpm_%.bbappend => rpm_git.bbappend} | 4 
>  1 file changed, 4 deletions(-)
>  rename recipes-devtools/rpm/{rpm_%.bbappend => rpm_git.bbappend} (56%)

I think I understand what you're looking to do here, but the comments
are completely unclear.  A commit log should look something like:

   rpm: move rpm recipe to rpm_git

   

   Signed-off-by: Dengke Du 
   ---
   

You can accomplish this with the --annotate flag to git-send-email and
then in your editor just ensure the revision history and additional
commentary goes after the --- line.

As for the change, deleting package contents that are no longer present
is fine, but why change % to git in the recipe name?  We moved from a
specific version number to % so we would be somewhat divorced from the
changes in oe-core, this change reverses that decision.

-J.

> diff --git a/recipes-devtools/rpm/rpm_%.bbappend 
> b/recipes-devtools/rpm/rpm_git.bbappend
> similarity index 56%
> rename from recipes-devtools/rpm/rpm_%.bbappend
> rename to recipes-devtools/rpm/rpm_git.bbappend
> index 199a7e4..9f3ec90 100644
> --- a/recipes-devtools/rpm/rpm_%.bbappend
> +++ b/recipes-devtools/rpm/rpm_git.bbappend
> @@ -1,8 +1,4 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>  
> -FILES_${PN} += "${libdir}/rpm/bin/spooktool \
> -${libdir}/rpm/bin/semodule \
> -   "
> -
>  inherit with-selinux
>  PACKAGECONFIG[selinux] = "${WITH_SELINUX},${WITHOUT_SELINUX},libsemanage,"
> -- 
> 2.11.0
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] selinux-image: enable image labelling

[Joe MacDonald]

selinux images attempt to label the filesystem image at creation time.
This depends on a native setfiles, though, which isn't guaranteed to be
present without the DEPEND addition.

If the 'setfiles' call fails, that shouldn't be fatal, though, it can
always be run at first boot time, as is commonly done with desktop and
server distros.

Signed-off-by: Joe MacDonald 
---
 classes/selinux-image.bbclass | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/classes/selinux-image.bbclass b/classes/selinux-image.bbclass
index 9303610..90ead2f 100644
--- a/classes/selinux-image.bbclass
+++ b/classes/selinux-image.bbclass
@@ -1,8 +1,15 @@
 selinux_set_labels () {
 POL_TYPE=$(sed -n -e 
"s&^SELINUXTYPE[[:space:]]*=[[:space:]]*\([0-9A-Za-z_]\+\)&\1&p" 
${IMAGE_ROOTFS}/${sysconfdir}/selinux/config)
-setfiles -r ${IMAGE_ROOTFS} 
${IMAGE_ROOTFS}/${sysconfdir}/selinux/${POL_TYPE}/contexts/files/file_contexts 
${IMAGE_ROOTFS} || exit 1;
+if ! setfiles -r ${IMAGE_ROOTFS} 
${IMAGE_ROOTFS}/${sysconfdir}/selinux/${POL_TYPE}/contexts/files/file_contexts 
${IMAGE_ROOTFS}
+then
+echo WARNING: Unable to set filesystem context, setfiles / restorecon 
must be run on the live image.
+touch ${IMAGE_ROOTFS}/.autorelabel
+exit 0
+fi
 }
 
+DEPENDS += "policycoreutils-native"
+
 IMAGE_PREPROCESS_COMMAND += "selinux_set_labels ;"
 
 inherit core-image
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] systemd: no need to inherit enable-selinux

[Joe MacDonald]

[[yocto] [meta-selinux][PATCH] systemd: no need to inherit enable-selinux] On 
17.02.22 (Wed 14:44) jackie.hu...@windriver.com wrote:

> From: Jackie Huang 
> 
> The selinux PACKAGECONFIG is properly handled in
> the recipe in oe-core, no need to inherit the
> enable-selinux bbclass.

That might be true, but other than belt-and-suspenders, what's the
harm in this being in the recipe?  I don't necessarily think it's an
invalid change but my quick count shows ~44 instances of 'inherit
enable-selinux' and 'inherit with-selinux' in meta-selinux, why's this
one significant?

-J.

> 
> Signed-off-by: Jackie Huang 
> ---
>  recipes-core/systemd/systemd_%.bbappend | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/recipes-core/systemd/systemd_%.bbappend 
> b/recipes-core/systemd/systemd_%.bbappend
> index 8d9029b..f1bdaf8 100644
> --- a/recipes-core/systemd/systemd_%.bbappend
> +++ b/recipes-core/systemd/systemd_%.bbappend
> @@ -1,2 +1 @@
>  inherit enable-audit
> -inherit enable-selinux
> -- 
> 2.8.3
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] No recipes available for meta-selinux and meta-virtualization layers

[Joe MacDonald]

Hi Pello,

[No recipes available for meta-selinux and meta-virtualization layers] On 
17.04.10 (Mon 09:59) Pello Heriz wrote:

> Hi,
> 
> I have tried to build a core-image-minimal image with master branch of
> Yocto and I have added the meta-virtualization layer and it's
> dependency layers in order to have virtualization functionalities
> enabled when creating the image.
> 
> The problem is that the bitbake execution fails due to there are
> missing some recipes for meta-selinux and meta-virtualization layers.
> This is the message that I can see in the terminal when it fails the
> execution:

Yeah, Mark and I have discussed a few times that we're sorely out of
date in meta-selinux right now.  At different times we've each said we
were going to do an update to the layer, but frankly we're both pretty
swamped and there's a couple of infrastructural issues too that we've
both been hoping to resolve "pretty soon".

That said, as a stop-gap, you could try checking out the updated
master-next branch in meta-selinux.  Just a few minutes ago I pushed
some changes that may resolve some of those issues for you.

Also, just FYI, I don't typically test anything in meta-selinux outside
of the combination with DISTRO=poky-selinux or oe-selinux and a
core-image-selinux, so you may encounter issues I haven't seen when
building something else.  But we're happy to take patches for those
additional cases, just know that you may be blazing your own trail.

-J.

> 
> pello@pello-VirtualBox:/opt/yocto_GE/yocto_master_xen/poky/build$ bitbake
> core-image-minimal
> Parsing recipes: 100% 
> |
> ##| Time: 0:09:00
> Parsing of 1981 .bb files complete (0 cached, 1981 parsed). 2752 targets, 204
> skipped, 0 masked, 0 errors.
> ERROR: No recipes available for:
>   /opt/yocto_GE/yocto_master_xen/poky/meta-selinux/recipes-devtools/rpm/
> rpm_5.4.16.bbappend
>   /opt/yocto_GE/yocto_master_xen/poky/meta-selinux/recipes-extended/findutils/
> findutils_4.2.31.bbappend
>   
> /opt/yocto_GE/yocto_master_xen/poky/meta-virtualization/recipes-kernel/linux/
> linux-yocto_4.8.bbappend
> 
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> 
> 
> How can be solved this error? Are you planned to update some patch for solving
> this issue?
> 
> Looking forward to your answer,
> Best regards,
> Pello

-- 
-Joe MacDonald.
:wq
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] deprecated.bbclass: Document PNDEPRECATED variable

[Joe MacDonald]

Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.  Update the
documentation to support this new variable.

Signed-off-by: Joe MacDonald 
---

This should only be added if or when the bbclass is merged into meta/

-J.

 documentation/ref-manual/ref-classes.xml   | 28 
 documentation/ref-manual/ref-variables.xml | 28 
 2 files changed, 56 insertions(+)

diff --git a/documentation/ref-manual/ref-classes.xml 
b/documentation/ref-manual/ref-classes.xml
index f7b1126..6088b44 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -632,6 +632,34 @@
 
 
 
+
+deprecated.bbclass
+
+
+The deprecated class identifies recipes
+that for one reason or another are being considered for removal
+from their current layer. It may be due to persistent, known
+issues with the package, that there are newer, more feature-rich
+alternatives available in the same layer or that the recipe is
+no longer needed.  The recipe should provide a reason for the
+depercation and a suggestion to consumers of the recipe as to how
+to proceed.
+To use this class, inherit the class globally and set
+PNDEPRECATED
+for each recipe you intend to deprecate.
+Specify the PN
+value as a variable flag (varflag) and provide a reason, which is
+reported, if the package is requested to be built as the value.
+For example, if you want to deprecate a recipe called "exoticware",
+you add the following to your local.conf
+or distribution configuration:
+
+ INHERIT += "deprecated"
+ PNDEPRECATED[exoticware] = "'exoticware' is considered obsolete and has 
been replaced by 'standardware'.  'exoticware' may not appear in future 
releases."
+
+
+
+
 
 devshell.bbclass
 
diff --git a/documentation/ref-manual/ref-variables.xml 
b/documentation/ref-manual/ref-variables.xml
index f79cdd2..629d167 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -9920,6 +9920,34 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = 
"${INC_PR}.3"
 
 
 
+PNDEPRECATED
+
+PNDEPRECATED[doc] = "Lists recipes that may be removed in a 
future release or have more actively maintained alternatives."
+
+
+
+
+Lists recipes that may be removed in a future release or
+have more actively maintained alternatives.
+This variable works in conjunction with the
+deprecated
+class, which the recipe must inherit globally.
+
+
+
+To identify a recipe as deprecated, inherit the class
+globally and use the variable in your
+local.conf file.
+Here is an example that will show a warning when
+myrecipe is included in a project:
+
+ INHERIT += "deprecated"
+ PNDEPRECATED[myrecipe] = "Recipe is no longer actively maintained, you 
should consider using 'mynewrecipe' as an alternative."
+
+
+
+
+
 POPULATE_SDK_POST_HOST_COMMAND
 
 POPULATE_SDK_POST_HOST_COMMAND[doc] = "Specifies a list of 
functions to call once the OpenEmbedded build system has created host part of 
the SDK."
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux] What's the point of refpolicy-minimum?

[Joe MacDonald]

Hi guys,

[Re: [meta-selinux] What's the point of refpolicy-minimum?] On 17.01.12 (Thu 
12:57) wenzong fan wrote:

> On 01/10/2017 10:48 PM, Joe MacDonald wrote:
> >Wenzong / Shrikant,
> >
> >I thought I knew the answer to the above question, and maybe my
> >understanding is still correct, but I think I need to ask it now anyway.
> >
> >I don't use refpolicy-minimum for anything, so when I did the updates to
> >refpolicy*_git I didn't even glance at refpolicy-minimum_git.  Wenzong's
> >change to refpolicy-minimum_2.20161023 (in the same thread as the uprev
> >of the recipe) piqued my curiosity, so I had a look.  Of course,
> >refpolicy-minimum_git.bb also needs to be updated (or thrown out), but
> >now that I'm looking at the recipe I see what seems like conflicting
> >statements in the recipe:
> >
> >   recipes-security/refpolicy/refpolicy-minimum_2.20161023.bb:
> >
> > 1 include refpolicy-targeted_${PV}.bb
> > 2
> > 3 SUMMARY = "SELinux minimum policy"
> > 4 DESCRIPTION = "\
> > 5 This is a minimum reference policy with just core policy modules, and 
> > \
> > 6 could be used as a base for customizing targeted policy. \
> > 7 Pretty much everything runs as initrc_t or unconfined_t so all of the 
> > \
> > 8 domains are unconfined. \
> > 9 "
> >
> >and:
> >
> >   recipes-security/refpolicy/refpolicy-targeted_2.20161023.bb:
> >
> > 1 SUMMARY = "SELinux targeted policy"
> > 2 DESCRIPTION = "\
> > 3 This is the targeted variant of the SELinux reference policy.  Most 
> > service \
> > 4 domains are locked down. Users and admins will login in with 
> > unconfined_t \
> > 5 domain, so they have the same access to the system as if SELinux was 
> > not \
> > 6 enabled. \
> > 7 "
> >
> >So now I'm trying to understand what the point of refpolicy-minimum
> >really is here.  Those of you who are using it, what are you using it
> >for and what do you expect would be the correct behaviour of a system
> >running that policy?
> >
> 
> I don't have much experience on using the refpolicy-minimum as well.
> 
> But from the original logs it should be "minimum targeted policy".
> 
> commit 65675f02e33f5da31ec5dbac7a45849f4952569b
> Author: Wenzong Fan 
> Date:   Mon Mar 24 21:07:50 2014 -0400
> 
> refpolicy: add minimum targeted policy
> 
> This is a minimum targeted policy with just core policy modules, and
> could be used as a base for customizing targeted policy.
> Pretty much everything runs as initrc_t or unconfined_t so all of the
> domains are unconfined.
> 
> Signed-off-by: Wenzong Fan 
> Signed-off-by: Joe MacDonald 
> 
> 
> >At the very least, I'm going to remove the 'include [...].bb' from both
> >'minimum' recipes, as that's completely incorrect, but when I do that I
> >want to know what anyone using this recipe wants to see from it, so
> >whatever the 'include' gets replaced with is doing the right thing
> >(which isn't necessarily what it's doing today).
> 
> I won't object to make the changes, if you think there should be a different
> minimum policy with targeted.

I'm not proposing an alternative, I'm just saying that the statements in
the descriptions of the recipes seem to conflict.  (And do note that the
git log you quoted is precisely the text in DESCRIPTION for
refpolicy-minimum.

What I'm confused by is this in minimum:

> Pretty much everything runs as initrc_t or unconfined_t so all of the
> domains are unconfined.

and this in targeted:

> > Most service domains are locked down.

So I guess my question is what is the desired behaviour out of this
recipe?  If nobody knows and it's not being used, I'm leaning toward a
'git rm'-based solution.  :-)

It sounds, though, like Shrikant is using it, so it's of some use, I
guess.  Shrikant, on the systems you've used the minimum policy, what
does the policy look like on your running system?  In the current world
refpolicy-minimum inherits POLICY_TYPE and POLICY_MLS_SENS from
refpolicy-targeted, is that good / bad / irrelevant to what you're doing
with it?  If I just rework minimum to remove the include and bring in
the minimal number of changes to get the policy to load again, is that
good enough for your purposes?  Do you want to volunteer to test my
changes for me before I commit them?  :-)

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023

[Joe MacDonald]

[Re: [yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023] On 
17.01.11 (Wed 10:24) wenzong fan wrote:

> On 01/10/2017 10:25 PM, Joe MacDonald wrote:
> >[[yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023] On 
> >17.01.10 (Tue 00:54) wenzong@windriver.com wrote:
> >
> >>From: Wenzong Fan 
> >>
> >>Uprev refpolicy to 2.20161023 and fix build errors for refpolicy-minimum.
> >>
> >>The following changes since commit bae51859f0dbcdde9fd563d15128a6dbbb816801:
> >>
> >>  audit: upgrade 2.6.6 -> 2.7 (2017-01-09 08:59:55 -0500)
> >>
> >>are available in the git repository at:
> >>
> >>  git://git.pokylinux.org/poky-contrib wenzong/refpolicy-2.20161023
> >>  
> >> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/refpolicy-2.20161023
> >
> >As poky-contrib is full of unrelated stuff, it's not the right place to
> >be doing meta-selinux work AFAICT.  I'd rather you actually just
> >fork meta-selinux somewhere like github if you plan to send pull
> >requests.  Patches are fine, of course, they're even easier for me to
> >work with.
> 
> Oko< I didn't notice that before, I'll fork it on github for my pull
> requests later.

You don't have to, patches are always fine with me.  I'm just letting
you know that I won't be pulling anything from your poky-contrib
branches for meta-selinux since they're completely different repos.

Thanks Wenzong.
-J.

> 
> Thanks
> Wenzong
> 
> >
> >-J.
> >
> >>
> >>Wenzong Fan (2):
> >>  refpolicy: uprev 2.20151208 -> 2.20161023
> >>  refpolicy-minimum: update patch file
> >>
> >> .../ftp-add-ftpd_t-to-mlsfilewrite.patch | 0
> >> .../poky-fc-clock.patch  | 0
> >> .../poky-fc-corecommands.patch   | 0
> >> .../poky-fc-dmesg.patch  | 0
> >> .../poky-fc-fix-bind.patch   | 0
> >> .../poky-fc-fix-real-path_login.patch| 0
> >> .../poky-fc-fix-real-path_resolv.conf.patch  | 0
> >> .../poky-fc-fix-real-path_shadow.patch   | 0
> >> .../poky-fc-fix-real-path_su.patch   | 0
> >> .../poky-fc-fstools.patch| 0
> >> .../poky-fc-ftpwho-dir.patch | 0
> >> .../poky-fc-iptables.patch   | 0
> >> .../poky-fc-mta.patch| 0
> >> .../poky-fc-netutils.patch   | 0
> >> .../poky-fc-nscd.patch   | 0
> >> .../poky-fc-rpm.patch| 0
> >> .../poky-fc-screen.patch | 0
> >> .../poky-fc-ssh.patch| 0
> >> .../poky-fc-su.patch | 0
> >> .../poky-fc-subs_dist.patch  | 0
> >> .../poky-fc-sysnetwork.patch | 0
> >> .../poky-fc-udevd.patch  | 0
> >> .../poky-fc-update-alternatives_hostname.patch   | 0
> >> .../poky-fc-update-alternatives_sysklogd.patch   | 0
> >> .../poky-fc-update-alternatives_sysvinit.patch   | 0
> >> .../poky-policy-add-rules-for-bsdpty_device_t.patch  | 0
> >> .../poky-policy-add-rules-for-syslogd_t-symlink.patch| 0
> >> .../poky-policy-add-rules-for-tmp-symlink.patch  | 0
> >> .../poky-policy-add-rules-for-var-cache-symlink.patch| 0
> >> .../poky-policy-add-rules-for-var-log-symlink-apache.patch   | 0
> >> ...ky-policy-add-rules-for-var-log-symlink-audisp_remote_t.patch | 0
> >> .../poky-policy-add-rules-for-var-log-symlink.patch  | 0
> >> .../poky-policy-add-syslogd_t-to-trusted-object.patch| 0
> >> .../poky-policy-allow-nfsd-to-exec-shell-commands.patch  | 0
> >> .../poky-policy-allow-setfiles_t-to-read-symlinks.patch  | 0
> >> .../poky-policy-allow-sysadm-to-run-rpcinfo.patch| 0
> >> .../poky-policy-don-t-audit-tty_device_t.patch   | 0
> >> .../poky-policy-fix-dmesg-to-use-dev-kmsg.

[yocto] [meta-selinux] What's the point of refpolicy-minimum?

[Joe MacDonald]

Wenzong / Shrikant,

I thought I knew the answer to the above question, and maybe my
understanding is still correct, but I think I need to ask it now anyway.

I don't use refpolicy-minimum for anything, so when I did the updates to
refpolicy*_git I didn't even glance at refpolicy-minimum_git.  Wenzong's
change to refpolicy-minimum_2.20161023 (in the same thread as the uprev
of the recipe) piqued my curiosity, so I had a look.  Of course,
refpolicy-minimum_git.bb also needs to be updated (or thrown out), but
now that I'm looking at the recipe I see what seems like conflicting
statements in the recipe:

   recipes-security/refpolicy/refpolicy-minimum_2.20161023.bb:

 1 include refpolicy-targeted_${PV}.bb
 2 
 3 SUMMARY = "SELinux minimum policy"
 4 DESCRIPTION = "\
 5 This is a minimum reference policy with just core policy modules, and \
 6 could be used as a base for customizing targeted policy. \
 7 Pretty much everything runs as initrc_t or unconfined_t so all of the \
 8 domains are unconfined. \
 9 "

and:

   recipes-security/refpolicy/refpolicy-targeted_2.20161023.bb:

 1 SUMMARY = "SELinux targeted policy"
 2 DESCRIPTION = "\
 3 This is the targeted variant of the SELinux reference policy.  Most 
service \
 4 domains are locked down. Users and admins will login in with 
unconfined_t \
 5 domain, so they have the same access to the system as if SELinux was not 
\
 6 enabled. \
 7 "

So now I'm trying to understand what the point of refpolicy-minimum
really is here.  Those of you who are using it, what are you using it
for and what do you expect would be the correct behaviour of a system
running that policy?

At the very least, I'm going to remove the 'include [...].bb' from both
'minimum' recipes, as that's completely incorrect, but when I do that I
want to know what anyone using this recipe wants to see from it, so
whatever the 'include' gets replaced with is doing the right thing
(which isn't necessarily what it's doing today).

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH 0/2] uprev refpolicy to 2.20161023

[Joe MacDonald]

_t.patch (100%)
>  rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
> refpolicy-2.20161023}/poky-policy-fix-dmesg-to-use-dev-kmsg.patch (100%)
>  rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
> refpolicy-2.20161023}/poky-policy-fix-new-SELINUXMNT-in-sys.patch (100%)
>  rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
> refpolicy-2.20161023}/poky-policy-fix-nfsd_t-to-mount_nfsd_fs_t.patch (100%)
>  rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
> refpolicy-2.20161023}/poky-policy-fix-setfiles-statvfs-get-file-count.patch 
> (100%)
>  rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
> refpolicy-2.20161023}/poky-policy-fix-seutils-manage-config-files.patch (100%)
>  rename recipes-security/refpolicy/{refpolicy-2.20151208 => 
> refpolicy-2.20161023}/refpolicy-update-for_systemd.patch (100%)
>  rename recipes-security/refpolicy/{refpolicy-mcs_2.20151208.bb => 
> refpolicy-mcs_2.20161023.bb} (100%)
>  rename recipes-security/refpolicy/{refpolicy-minimum_2.20151208.bb => 
> refpolicy-minimum_2.20161023.bb} (100%)
>  rename recipes-security/refpolicy/{refpolicy-mls_2.20151208.bb => 
> refpolicy-mls_2.20161023.bb} (100%)
>  rename recipes-security/refpolicy/{refpolicy-standard_2.20151208.bb => 
> refpolicy-standard_2.20161023.bb} (100%)
>  rename recipes-security/refpolicy/{refpolicy-targeted_2.20151208.bb => 
> refpolicy-targeted_2.20161023.bb} (100%)
>  rename recipes-security/refpolicy/{refpolicy_2.20151208.inc => 
> refpolicy_2.20161023.inc} (91%)
> 
> -- 
> 2.11.0
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] refpolicy-git: Update patches

[Joe MacDonald]

A number of upstream changes caused patch conflicts or duplication in the
final policy.  Update the list of git patches appropriately.

Signed-off-by: Joe MacDonald 
---
 .../ftp-add-ftpd_t-to-mlsfilewrite.patch   |  11 +-
 .../refpolicy/refpolicy-git/poky-fc-clock.patch|  11 +-
 .../refpolicy-git/poky-fc-corecommands.patch   |  24 
 .../refpolicy/refpolicy-git/poky-fc-dmesg.patch|  11 +-
 .../refpolicy/refpolicy-git/poky-fc-fix-bind.patch |   9 +-
 .../poky-fc-fix-real-path_login.patch  |  20 ++--
 .../poky-fc-fix-real-path_resolv.conf.patch|  13 +--
 .../poky-fc-fix-real-path_shadow.patch |  11 +-
 .../refpolicy-git/poky-fc-fix-real-path_su.patch   |   9 +-
 .../refpolicy/refpolicy-git/poky-fc-fstools.patch  |  33 +++---
 .../refpolicy-git/poky-fc-ftpwho-dir.patch |  13 +--
 .../refpolicy/refpolicy-git/poky-fc-iptables.patch |  24 
 .../refpolicy/refpolicy-git/poky-fc-mta.patch  |  11 +-
 .../refpolicy/refpolicy-git/poky-fc-netutils.patch |  13 +--
 .../refpolicy/refpolicy-git/poky-fc-nscd.patch |   9 +-
 .../refpolicy/refpolicy-git/poky-fc-rpm.patch  |   9 +-
 .../refpolicy/refpolicy-git/poky-fc-screen.patch   |  12 +-
 .../refpolicy/refpolicy-git/poky-fc-ssh.patch  |  15 ++-
 .../refpolicy/refpolicy-git/poky-fc-su.patch   |  23 
 .../refpolicy-git/poky-fc-subs_dist.patch  |  15 ++-
 .../refpolicy-git/poky-fc-sysnetwork.patch |  23 ++--
 .../refpolicy/refpolicy-git/poky-fc-udevd.patch|  21 ++--
 .../poky-fc-update-alternatives_hostname.patch |   9 +-
 .../poky-fc-update-alternatives_sysklogd.patch |  20 ++--
 .../poky-fc-update-alternatives_sysvinit.patch |  27 +++--
 ...poky-policy-add-rules-for-bsdpty_device_t.patch |  53 ++---
 ...ky-policy-add-rules-for-syslogd_t-symlink.patch |  13 +--
 .../poky-policy-add-rules-for-tmp-symlink.patch|  63 ---
 ...ky-policy-add-rules-for-var-cache-symlink.patch |  11 +-
 ...licy-add-rules-for-var-log-symlink-apache.patch |  11 +-
 ...rules-for-var-log-symlink-audisp_remote_t.patch |  13 +--
 ...poky-policy-add-rules-for-var-log-symlink.patch |  81 ++
 ...ky-policy-add-syslogd_t-to-trusted-object.patch |  11 +-
 ...-policy-allow-nfsd-to-exec-shell-commands.patch |  21 ++--
 ...-policy-allow-setfiles_t-to-read-symlinks.patch |  11 +-
 .../poky-policy-allow-sysadm-to-run-rpcinfo.patch  |  11 +-
 .../poky-policy-don-t-audit-tty_device_t.patch |  11 +-
 .../poky-policy-fix-dmesg-to-use-dev-kmsg.patch|  17 ++-
 .../poky-policy-fix-new-SELINUXMNT-in-sys.patch| 124 -
 ...poky-policy-fix-nfsd_t-to-mount_nfsd_fs_t.patch |  26 -
 ...olicy-fix-setfiles-statvfs-get-file-count.patch |  11 +-
 ...ky-policy-fix-seutils-manage-config-files.patch |  19 ++--
 .../refpolicy-update-for_systemd.patch |   9 +-
 recipes-security/refpolicy/refpolicy_common.inc|   4 +
 recipes-security/refpolicy/refpolicy_git.inc   |   3 -
 45 files changed, 501 insertions(+), 418 deletions(-)
 delete mode 100644 
recipes-security/refpolicy/refpolicy-git/poky-fc-corecommands.patch
 delete mode 100644 
recipes-security/refpolicy/refpolicy-git/poky-fc-iptables.patch
 delete mode 100644 recipes-security/refpolicy/refpolicy-git/poky-fc-su.patch

diff --git 
a/recipes-security/refpolicy/refpolicy-git/ftp-add-ftpd_t-to-mlsfilewrite.patch 
b/recipes-security/refpolicy/refpolicy-git/ftp-add-ftpd_t-to-mlsfilewrite.patch
index 49da4b6..4830566 100644
--- 
a/recipes-security/refpolicy/refpolicy-git/ftp-add-ftpd_t-to-mlsfilewrite.patch
+++ 
b/recipes-security/refpolicy/refpolicy-git/ftp-add-ftpd_t-to-mlsfilewrite.patch
@@ -21,11 +21,11 @@ Signed-off-by: Roy Li 
  policy/modules/contrib/ftp.te |2 ++
  1 file changed, 2 insertions(+)
 
-diff --git a/policy/modules/contrib/ftp.te b/policy/modules/contrib/ftp.te
-index 544c512..12a31dd 100644
 --- a/policy/modules/contrib/ftp.te
 +++ b/policy/modules/contrib/ftp.te
-@@ -144,6 +144,8 @@ role ftpdctl_roles types ftpdctl_t;
+@@ -148,10 +148,12 @@ init_system_domain(ftpdctl_t, ftpdctl_ex
+ role ftpdctl_roles types ftpdctl_t;
+ 
  type ftpdctl_tmp_t;
  files_tmp_file(ftpdctl_tmp_t)
  
@@ -34,6 +34,5 @@ index 544c512..12a31dd 100644
  type sftpd_t;
  domain_type(sftpd_t)
  role system_r types sftpd_t;
--- 
-1.7.10.4
-
+ 
+ type xferlog_t;
diff --git a/recipes-security/refpolicy/refpolicy-git/poky-fc-clock.patch 
b/recipes-security/refpolicy/refpolicy-git/poky-fc-clock.patch
index 3ff8f55..b36c209 100644
--- a/recipes-security/refpolicy/refpolicy-git/poky-fc-clock.patch
+++ b/recipes-security/refpolicy/refpolicy-git/poky-fc-clock.patch
@@ -4,19 +4,16 @@ Upstream-Status: Inappropriate [configuration]
 
 Signed-off-by: Xin Ouyang 
 ---
- policy/modules/system/clock.fc | 1 +
+ policy/modules/system/clock.fc |1 +
  1 file changed, 1 insertion(+)
 
-diff --git a/policy/modules/system/clock.fc b/policy/modules/system/clock.fc
-index c5e05ca..a74c40c 100644
 --- a/policy

[yocto] [meta-selinux][PATCH] eudev: remove explicit setenforce call in init

[Joe MacDonald]

When using udev-cache, the eudev init script had been explicitly calling
'setenforce 1'. That's no longer necessary with updates to other parts of
eudev and the presence of the call prevented booting core-image-selinux*
systems in permissive mode.  Remove the call to allow permissive booting.

[YOCTO #7506]

Signed-off-by: Joe MacDonald 
---

The Yocto bug mentions asked whether removing this setenforce call (that is,
allowing booting in permissive mode) would cause new warnings / errors /
whatever or would potentially even prevent booting at all.  I tried to cover the
various cases in my testing and I've captured the boot logs here:

   http://pastebin.com/EEahVmzd
   http://pastebin.com/Qxa3BHHE
   http://pastebin.com/4XE9Zhg8

And on review I don't see anything significant in the differences.  That said,
an extra set of eyes (or two) would be appropriate, I think, which is why I
posted the logs.  I zeroed out all the timestamps for the sake of making diffs
less noisy.

Philip: Since you authored the original commit here, I'd like you to weigh in on
the sanity of this change, even though the bug is specifically referencing a
commit I did long ago.

One caveat with this, and you'll see it in the logs, I'm right now observing
that if the system doesn't boot into enforcing mode on the first boot, switching
to enforcing mode requires a reboot, but I think that's a function of the first
boot relabling and udev-cache squabbling.  Subsequent boots of all three
scenarios didn't have any issues with logins, as far as I could tell, and
requiring a reboot when doing policy-related work on a first boot of an SELinux
system isn't all that unexpected, from my experience.

Thoughts?

-J.

 recipes-core/eudev/eudev/init | 1 -
 1 file changed, 1 deletion(-)

diff --git a/recipes-core/eudev/eudev/init b/recipes-core/eudev/eudev/init
index 9a4b293..ee64f86 100644
--- a/recipes-core/eudev/eudev/init
+++ b/recipes-core/eudev/eudev/init
@@ -89,7 +89,6 @@ case "$1" in
fi
echo "$NEWDATA" > /dev/shm/udev.cache
fi
-   /usr/sbin/setenforce 1
else
if [ "$ROOTFS_READ_ONLY" != "yes" ]; then
# If rootfs is not read-only, it's possible 
that a new udev cache would be generated;
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] augeas: Move to meta-python optional layer

[Joe MacDonald]

Augeas lives in meta-python, but meta-selinux shouldn't specifically
require meta-python in every build, so make the bbappend optional using
the standard mechanism already present in the layer.conf.

Signed-off-by: Joe MacDonald 
---
 meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend | 1 +
 recipes-extended/augeas/augeas_%.bbappend| 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)
 create mode 100644 meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend
 delete mode 100644 recipes-extended/augeas/augeas_%.bbappend

diff --git a/meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend 
b/meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend
new file mode 100644
index 000..c1e8ed6
--- /dev/null
+++ b/meta-python/recipes-extended/augeas/augeas/augeas_%.bbappend
@@ -0,0 +1 @@
+inherit with-selinux
diff --git a/recipes-extended/augeas/augeas_%.bbappend 
b/recipes-extended/augeas/augeas_%.bbappend
deleted file mode 100644
index c1e8ed6..000
--- a/recipes-extended/augeas/augeas_%.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-inherit with-selinux
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] refpolicy: remove virtual prefix for runtime providers

[Joe MacDonald]

In keeping with the approach of only providing a single default policy at
runtime, we were originally using a virtual/refpolicy dependency and
filling it with one of our specific refpolicy implementations.  This works
well enough for some package systems, but fails for others (specifically
deb, possibly more).

Since the intent was to only have one present in the default image anyway,
we'll just throw out the 'virtual/' part of the RPROVIDES and related
dependencies across the board.

Signed-off-by: Joe MacDonald 
---

In terms of testing on this change, my primary approach was to compare
before/after manifests and ensure that what lands on the filesystem image
hasn't changed.  It is another subtle change to behaviour that I know
isn't unanimously embraced anyway, so I'm happy to discuss alternative
options.  My objective here was just to enable deb support (and to get my
autobuilder to stop complaining about it).

 recipes-security/packagegroups/packagegroup-core-selinux.bb| 2 +-
 recipes-security/packagegroups/packagegroup-selinux-minimal.bb | 2 +-
 recipes-security/refpolicy/refpolicy_common.inc| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-security/packagegroups/packagegroup-core-selinux.bb 
b/recipes-security/packagegroups/packagegroup-core-selinux.bb
index c6d22b7..9c74458 100644
--- a/recipes-security/packagegroups/packagegroup-core-selinux.bb
+++ b/recipes-security/packagegroups/packagegroup-core-selinux.bb
@@ -25,6 +25,6 @@ RDEPENDS_${PN} = " \
selinux-autorelabel \
selinux-init \
selinux-labeldev \
-   virtual/refpolicy \
+   refpolicy \
coreutils \
"
diff --git a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb 
b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
index 451ae8b..eac4b94 100644
--- a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
+++ b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
@@ -22,5 +22,5 @@ RDEPENDS_${PN} = "\
policycoreutils-sestatus \
policycoreutils-setfiles \
selinux-labeldev \
-   virtual/refpolicy \
+   refpolicy \
 "
diff --git a/recipes-security/refpolicy/refpolicy_common.inc 
b/recipes-security/refpolicy/refpolicy_common.inc
index 1d3b93f..e1eac50 100644
--- a/recipes-security/refpolicy/refpolicy_common.inc
+++ b/recipes-security/refpolicy/refpolicy_common.inc
@@ -6,7 +6,7 @@ LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=393a5ca445f6965873eca0259a17f833"
 
 PROVIDES += "virtual/refpolicy"
-RPROVIDES_${PN} += "virtual/refpolicy"
+RPROVIDES_${PN} += "refpolicy"
 
 # Specific config files for Poky
 SRC_URI += "file://customizable_types \
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] e2fsprogs: Update bbappend

[Joe MacDonald]

e2fsprogs has been updated with oe-core commit
f221f331704c0bdfc7c1dd361e666ce2158fe282  Update our bbappend accordingly.

Signed-off-by: Joe MacDonald 
---
 .../e2fsprogs/{e2fsprogs_git.bbappend => e2fsprogs_%.bbappend}| 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename recipes-devtools/e2fsprogs/{e2fsprogs_git.bbappend => 
e2fsprogs_%.bbappend} (100%)

diff --git a/recipes-devtools/e2fsprogs/e2fsprogs_git.bbappend 
b/recipes-devtools/e2fsprogs/e2fsprogs_%.bbappend
similarity index 100%
rename from recipes-devtools/e2fsprogs/e2fsprogs_git.bbappend
rename to recipes-devtools/e2fsprogs/e2fsprogs_%.bbappend
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ifenslave recipe

[Joe MacDonald]

Hi Paul,

[[yocto] ifenslave recipe] On 16.06.16 (Thu 13:40) Stath, Paul wrote:

> I'm looking at adding support for NIC bonding into our distribution.
> 
> Along with bonding support in the kernel, I would like to build the 
> 'ifenslave'
> utility program.
> 
> In checking the OpenEmbedded Layer Index, I find recipes-support/ifenslave/
> ifenslave_1.1.0.bb in the meta-networking layer.
> 
> This recipe has a SRC_URI for a version of 'ifenslave.c'
> (ifenslace-2.6_1.1.0.org.tar.gz) which I hazard to guess is based on the
> ifenslave distributed with the 2.6 kernel sources.
> 
> The documentation for bonding (http://www.linuxfoundation.org/collaborate/
> workgroups/networking/bonding) recommends using the 'ifenslave.c' distributed
> with the kernel sources.  It does indicate that sources from an earlier kernel
> should still work, but may not support new functionallity.


Actually, ifenslave has been gone from the kernel sources tree for some
time now:

commit b1098bbe1b24d5d90cff92fbd716d2ef4bed2cff
Author: Cong Wang 
Date:   Mon May 27 15:49:16 2013 +

bonding: remove ifenslave.c from kernel source

As Stephen proposed:
Since bonding supports configuration via iproute (netlink) and sysfs, I 
think
it is time to purge the old ifenslave code out of Documentation/networking
and update the documentation.

Suggested-by: Stephen Hemminger 
Cc: Stephen Hemminger 
Cc: Jay Vosburgh 
Cc: "David S. Miller" 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 

so if anything that's probably an argument for us purging the recipe in
meta-networking too.

> Ideally, I would like to add a .bbappend to the linux-yocto recipe in my layer
> that will compile and package the ifenslave program if "CONFIG_BONDING=[m|y]"
> is configured for the kernel build.

Are you sure you need ifenslave at all?  If so, then either you can
submit and updated recipe that grabs the last ifenslave.c (~3.10) or
I'll see if I can put together a quick update to the recipe.  Otherwise
it's probably time to put ifenslave out to pasture.

-J.

> 
> I'm unsure of the best way to determine if CONFIG_BONDING=[m|y].  Is is as
> simple as "grep '^CONFIG_BONDING=[m|y] .config"?
> 
> If bonding is enabled:
> 
> + do_compile_append() to compile ifenslave.c sources from kernel source tree.
> + do_install_append() to stage ifenslave executable
> + Update the "PACKAGES" variable to add "ifenslave" as a package.
> + Add FILES_ifenslave variable to define the contents of the ifenslave 
> package.
> 
> Please correct the above if I have missed something, made an invalid
> assumption, or am barking up the wrong tree.
> 
> --
> Paul Stath
> Senior Software Engineer
> Axxcelera Broadband Wireless
> Richmond, VA 23228
> 
> 
> 
> 
> 
> 

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into refpolicy_common.

[Joe MacDonald]

Philip / Wenzong,

[Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into 
refpolicy_common.] On 16.04.12 (Tue 13:54) wenzong fan wrote:

> On 04/12/2016 11:55 AM, Philip Tricca wrote:
> >Hello,
> >
> >On 04/11/2016 05:54 AM, Joe MacDonald wrote:
> >>>This causes do_populate_sysroot error if build two or more types of
> >>>refpolicy:
> >>>
> >>>$ bitbake refpolicy-minimum && bitbake refpolicy-mls
> >>>
> >>>ERROR: refpolicy-mls-git-r0 do_populate_sysroot: The recipe refpolicy-mls 
> >>>is
> >>>trying to install files into a shared area when those files already exist.
> >>>Those files and their manifest location are:
> >>
> >>I think this was always the intent with the series Philip submitted last
> >>week (for reference, the thread is
> >>https://www.mail-archive.com/yocto@yoctoproject.org/msg28530.html).
> >>Isn't this (part of) the expected behaviour of the virtual provider
> >>mechanism?
> >
> >This is the question I think we need to figure out. My understanding
> >(quite possibly wrong) is that the virtual provider stuff would prevent
> >the installation of more than one provider. I hadn't considered the
> >implications for the sysroot.
> >
> >Is the ability to install multiple providers in the sysroot expected? I
> >imagine that this problem must have been solved before in another
> >package with virtual providers that install the same file. I'm happy to
> >doing some digging here but if anyone knows of a good example I'd
> >appreciate a pointer.
> >
> >>We did discuss what it would mean to be trying out multiple
> >>policies on a system at the same time and at the time it seemed like the
> >>"just works" angle was more important than "buffet style" when it came
> >>to providing policy on the image.
> >
> >I guess the thing I like the most about setting the policy package up as
> >a virtual package is the ability to select the policy type as a distro
> >config. The virtual provider seemed like a natural fit as it's a pattern
> >that similar packages (kernel etc) use extensively.
> >
> >>It might be worth considering extending the changes to only do some
> >>install steps at, say, do_rootfs but I don't know if that even makes
> >>sense, this is really the first I've thought of it.  I think Philip's
> >>original changes are good, though, for our maintenance and for clients
> >>of meta-selinux.
> >
> >There may be a middle ground and I think that would be leaving the
> >configuration file as a separate package. Personally I liked the idea of
> >rolling the config file into the policy package as it was always a bit
> >awkward requiring coordination of some variables across the policy and
> >the config package which made it a bit brittle.
> >
> >Wenzong: A few questions: What's your use case for building multiple
> >policy packages? Would you suggest just backing out the removal of the
> >config package or the whole virtual provider thing?
> 
> Hi Philip,
> 
> The virtual provider is OK, just restore the config package is the simplest
> ways for fixing such issue I think.
> 
> My use cases include:
> a. update refpolicy and build each type to make sure patch/build/install
> work;

That's not necessarily an argument against the change ...

> b. run world build with meta-selinux layer.

... but I think this is.  Or, rather, I think what we have now makes more
sense from an end-user perspective, that your image wouldn't have more
than a single policy installed at a time and that if you tried to install
multiple policies for nearly everyone this represents a mistake and
undesirable behaviour so warnings / errors are appropriate.

But if this is breaking world builds with yocto+meta-selinux, that's
something I'd like to repair.  Though I'm surprised that what we have
right now would break the world builds.  Philip / Wenzong / Mark:  Do you
have publicly-accessible world builds right now?  I don't and I don't have
world builds for yocto+meta-selinux on my autobuilder, but I'll go set one
up if you don't have one.

-J.

> 
> Thanks
> Wenzong
> 
> >
> >Thanks,
> >Philip
> >
> >>>/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/sepolgen.conf
> >>>  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
> >>>
> >>>/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc

Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into refpolicy_common.

[Joe MacDonald]

pp \
> > ${localstatedir}/lib/selinux/${POLICY_NAME}/ \
> >@@ -25,7 +28,6 @@ FILES_${PN}-dev =+ " \
> >  "
> >
> >  DEPENDS += "checkpolicy-native policycoreutils-native m4-native"
> >-RDEPENDS_${PN} += "selinux-config"
> >
> >  PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> >@@ -137,13 +139,37 @@ install_misc_files () {
> > oe_runmake 'DESTDIR=${D}' 'prefix=${D}${prefix}' install-headers
> >  }
> >
> >+install_config () {
> >+echo "\
> >+# This file controls the state of SELinux on the system.
> >+# SELINUX= can take one of these three values:
> >+# enforcing - SELinux security policy is enforced.
> >+# permissive - SELinux prints warnings instead of enforcing.
> >+# disabled - No SELinux policy is loaded.
> >+SELINUX=${DEFAULT_ENFORCING}
> >+# SELINUXTYPE= can take one of these values:
> >+# standard - Standard Security protection.
> >+# mls - Multi Level Security protection.
> >+# targeted - Targeted processes are protected.
> >+# mcs - Multi Category Security protection.
> >+SELINUXTYPE=${POLICY_TYPE}
> >+" > ${WORKDIR}/config
> >+install -d ${D}/${sysconfdir}/selinux
> >+install -m 0644 ${WORKDIR}/config ${D}/${sysconfdir}/selinux/
> >+}
> >+
> >  do_install () {
> > prepare_policy_store
> > rebuild_policy
> > install_misc_files
> >+install_config
> >  }
> >
> >  do_install_append(){
> > # While building policies on target, Makefile will be searched from 
> > SELINUX_DEVEL_PATH
> > echo "SELINUX_DEVEL_PATH=${datadir}/selinux/${POLICY_NAME}/include" > 
> > ${D}${sysconfdir}/selinux/sepolgen.conf
> >  }
> >+
> >+sysroot_stage_all_append () {
> >+sysroot_stage_dir ${D}${sysconfdir} ${SYSROOT_DESTDIR}${sysconfdir}
> >+}
> >diff --git a/recipes-security/selinux/selinux-config_0.1.bb 
> >b/recipes-security/selinux/selinux-config_0.1.bb
> >deleted file mode 100644
> >index e902e98..000
> >--- a/recipes-security/selinux/selinux-config_0.1.bb
> >+++ /dev/null
> >@@ -1,40 +0,0 @@
> >-DEFAULT_ENFORCING ??= "enforcing"
> >-
> >-SUMMARY = "SELinux configuration"
> >-DESCRIPTION = "\
> >-SELinux configuration files for Yocto. \
> >-"
> >-
> >-SECTION = "base"
> >-LICENSE = "MIT"
> >-LIC_FILES_CHKSUM = 
> >"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
> >-PR = "r4"
> >-
> >-S = "${WORKDIR}"
> >-
> >-CONFFILES_${PN} += "${sysconfdir}/selinux/config"
> >-
> >-PACKAGE_ARCH = "${MACHINE_ARCH}"
> >-
> >-do_install () {
> >-echo "\
> >-# This file controls the state of SELinux on the system.
> >-# SELINUX= can take one of these three values:
> >-# enforcing - SELinux security policy is enforced.
> >-# permissive - SELinux prints warnings instead of enforcing.
> >-# disabled - No SELinux policy is loaded.
> >-SELINUX=${DEFAULT_ENFORCING}
> >-# SELINUXTYPE= can take one of these values:
> >-# standard - Standard Security protection.
> >-# mls - Multi Level Security protection.
> >-# targeted - Targeted processes are protected.
> >-# mcs - Multi Category Security protection.
> >-SELINUXTYPE=${@d.getVar("PREFERRED_PROVIDER_virtual/refpolicy", 
> >False)[len("refpolicy-"):]}
> >-" > ${WORKDIR}/config
> >-install -d ${D}/${sysconfdir}/selinux
> >-install -m 0644 ${WORKDIR}/config ${D}/${sysconfdir}/selinux/
> >-}
> >-
> >-sysroot_stage_all_append () {
> >-sysroot_stage_dir ${D}${sysconfdir} ${SYSROOT_DESTDIR}${sysconfdir}
> >-}
> >

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH 0/3] refpolicy virtual package

[Joe MacDonald]

[[yocto] [meta-selinux][PATCH 0/3] refpolicy virtual package] On 16.04.04 (Mon 
00:21) Philip Tricca wrote:

> We currently require each image to depend on the policy (or multiple
> policies) that they want installed and the selinux-config package
> enables the DEFAULT_POLICY. Since only one policy can be in effect at a
> time, and we're targeting "embedded" systems it makes sense (to me at
> least) that we would treat the policy much like we do the kernel and use
> a virtual provider.
> 
> Feedback would be much appreciated,
> Philip
> 
> Philip Tricca (3):
>   refpolicy: Setup virtual/refpolicy provider.
>   Integrate selinux-config into refpolicy_common.
>   refpolicy_common: Sanity test DEFAULT_ENFORCING value and set default.
> 
>  conf/distro/oe-selinux.conf|  1 +
>  .../packagegroups/packagegroup-core-selinux.bb |  4 +-
>  .../packagegroups/packagegroup-selinux-minimal.bb  |  3 +-
>  recipes-security/refpolicy/refpolicy_common.inc| 43 
> +-
>  recipes-security/selinux/selinux-config_0.1.bb | 41 -
>  5 files changed, 44 insertions(+), 48 deletions(-)
>  delete mode 100644 recipes-security/selinux/selinux-config_0.1.bb

I've tried this out today and it all looks good to me, I've tried
breaking the sanity check on DEFAULT_ENFORCING as we discussed and it
still seems to do the right thing.  Since this is what we were
discussing last week and it seemed to make sense at the time, I went
ahead and merged your patches for you.

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux] git recipes

[Joe MacDonald]

[Re: [yocto] [meta-selinux] git recipes] On 16.03.02 (Wed 19:59) Philip Tricca 
wrote:

> On 03/02/2016 07:47 AM, Radzykewycz, T (Radzy) wrote:
> > 
> > On 3/1/16 21:40, Philip Tricca wrote:
> >> On 03/01/2016 10:30 AM, Joe MacDonald wrote:
> >>> [Re: [yocto] [meta-selinux] git recipes] On 16.02.29 (Mon 08:06) Mark 
> >>> Hatle wrote:
> >>>
> >>>> On 2/27/16 10:23 PM, Philip Tricca wrote:
> >>>>> Adding a sensible subject.
> >>>>
> >>>> Sorry couldn't reply when I saw this when you first sent it.  Corporate 
> >>>> email
> >>>> server went down for those of us who DON'T use outlook.. argh..
> >>>>
> >>>> Anyway..
> >>>>
> >>>> What I'm generally used to in the Yocto Project work is that the 'git' 
> >>>> version
> >>>> picks a specific git snapshot and makes it a quick operation for someone 
> >>>> to
> >>>> arbitrarily change that snapshot by adjusting the SRCREV.
> >>>
> >>> This has been the approach I'd always tried to take with _git recipes as
> >>> well and it tends to work very well for ones that are either the only or
> >>> the preferred recipe.  I think in our case we were always preferring the
> >>> released versions for several historical reasons and the _git recipes were
> >>> relegated to the second-tier because of it.  But that means that basically
> >>> they never got updated.
> >>>
> >>> About a year and a half ago I started seriously talking about dumping the
> >>> userspace tools entirely and only ever working out of the _git recipes.
> >>> Shrikant started doing that work after I discussed it with him but we
> >>> never got beyond the policy recipes.  So if you guys think this is not a
> >>> completely insane thing to do, that's the direction I'd like to go with
> >>> this.
> >>>
> >>>> We don't use the AUTOREV parameter, because that causes the system to 
> >>>> have to do
> >>>> a git pull in order to evaluate the available versions and determine the 
> >>>> SRCREV
> >>>> to use.  So it's all down to a parsing and performance issue.
> >>>
> >>> And avoiding surprises on the other side of the bathtub curve, when
> >>> updates pop up that we aren't prepared for.  :-)  But we've been behind
> >>> on developments aging out, too, so I don't have a strong case to argue
> >>> against AUTOREV.
> >>>
> >>>> What I've done on some of my own projects is have an AUTOREV version 
> >>>> (locally),
> >>>> then when it triggers a recipe breakage, I think update the SRCREV and 
> >>>> fix it in
> >>>> the remote tree..  so I get the autorev, the world gets a version of the 
> >>>> package
> >>>> that keeps working.  (I also update the SRCREV other times as well.. but 
> >>>> the
> >>>> autorev breakage is one of the key triggers.)
> >>>>
> >>>> Joe might have some suggestions as well, I'm not against AUTOREV per 
> >>>> say, but I
> >>>> am worried about any performance issues during the parse.
> >>>
> >>> I would really rather avoid AUTOREV, but I think the way we would
> >>> accomplish that is to edge away from our current recipes and bring the
> >>> _git ones back to centre stage.  Then we're likely to stay on top of a
> >>> fixed SRCREV anyway.
> >>
> >> I think there's something to be said for a simple approach. For those
> >> showing up and trying to figure out what's going on / how the build
> >> works it would likely ease their entry if we had straight forward
> >> recipes that build from the usptream release tarballs. For those wanting
> >> to verify hashes published by upstream (and maybe signed) this makes
> >> life easier as well.
> > 
> > My comments, FWIW:
> > 
> > I'm not sure I agree that having both recipes is a simple approach.
> > 
> > If you're getting started, then you may not be aware of how
> > PREFERRED_VERSION works, or even that it is available at all.
> > Depending on your personal inclination, you may assume one way
> > or the other.

I'm somewhat in agreement with Radzy here, 

Re: [yocto] [meta-selinux][PATCH] udev: Rename udev bbappend to eudev.

[Joe MacDonald]

t; /dev/null 
> > 2>&1
> > -   not_first_boot=1
> > -   [ "$VERBOSE" != "no" ] && echo "udev: using 
> > cache file $DEVCACHE"
> > -   [ -e /dev/shm/udev.cache ] && rm -f 
> > /dev/shm/udev.cache
> > -   else
> > -   # Output detailed reason why the cached 
> > /dev is not used
> > -   if [ "$VERBOSE" != "no" ]; then
> > -   echo "udev: udev cache not used"
> > -   echo "udev: we use $CMP_FILE_LIST 
> > as criteria to judge whether the cache /dev could be resued"
> > -   echo "udev: olddata: $OLDDATA"
> > -   echo "udev: newdata: $NEWDATA"
> > -   fi
> > -   echo "$NEWDATA" > /dev/shm/udev.cache
> > -   fi
> > -   /usr/sbin/setenforce 1
> > -   else
> > -   if [ "$ROOTFS_READ_ONLY" != "yes" ]; then
> > -   # If rootfs is not read-only, it's possible 
> > that a new udev cache would be generated;
> > -   # otherwise, we do not bother to read files.
> > -   readfiles $CMP_FILE_LIST
> > -   echo "$READDATA" > /dev/shm/udev.cache
> > -   fi
> > -   fi
> > -   fi
> > -fi
> > -
> > -# make_extra_nodes
> > -kill_udevd > "/dev/null" 2>&1
> > -
> > -# trigger the sorted events
> > -echo -e '\000\000\000\000' > /proc/sys/kernel/hotplug
> > -@UDEVD@ -d
> > -
> > -udevadm control --env=STARTUP=1
> > -if [ "$not_first_boot" != "" ];then
> > -udevadm trigger --action=add --subsystem-nomatch=tty 
> > --subsystem-nomatch=mem --subsystem-nomatch=vc 
> > --subsystem-nomatch=vtconsole --subsystem-nomatch=misc 
> > --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus  
> > --subsystem-nomatch=graphics   --subsystem-nomatch=backlight 
> > --subsystem-nomatch=video4linux  --subsystem-nomatch=platform
> > -(udevadm settle --timeout=10; udevadm control --env=STARTUP=)&
> > -else
> > -udevadm trigger --action=add
> > -udevadm settle
> > -fi
> > -
> > -test ! -x /sbin/restorecon || /sbin/restorecon -F /dev /dev/shm 
> > /dev/pts
> > -
> > -;;
> > -  stop)
> > -echo "Stopping udevd"
> > -start-stop-daemon --stop --name udevd --quiet
> > -;;
> > -  restart)
> > -$0 stop
> > -sleep 1
> > -$0 start
> > -;;
> > -  status)
> > -pid=`pidof -x udevd`
> > -if [ -n "$pid" ]; then
> > -   echo "udevd (pid $pid) is running ..."
> > -else
> > -   echo "udevd is stopped"
> > -fi
> > -;;
> > -  *)
> > -echo "Usage: $0 {start|stop|status|restart}"
> > -exit 1
> > -esac
> > -exit 0
> > diff --git a/recipes-core/udev/udev/udev-cache 
> > b/recipes-core/udev/udev/udev-cache
> > deleted file mode 100644
> > index 6898577..000
> > --- a/recipes-core/udev/udev/udev-cache
> > +++ /dev/null
> > @@ -1,32 +0,0 @@
> > -#!/bin/sh -e
> > -
> > -### BEGIN INIT INFO
> > -# Provides:  udev-cache
> > -# Required-Start:mountall
> > -# Required-Stop:
> > -# Default-Start: S
> > -# Default-Stop:
> > -# Short-Description: cache /dev to speedup the udev next boot
> > -### END INIT INFO
> > -
> > -export TZ=/etc/localtime
> > -
> > -[ -r /proc/mounts ] || exit 1
> > -[ -x @UDEVD@ ] || exit 1
> > -[ -d /sys/class ] || exit 1
> > -
> > -[ -f /etc/default/rcS ] && . /etc/default/rcS
> > -[ -f /etc/default/udev-cache ] && . /etc/default/udev-cache
> > -
> > -if [ "$ROOTFS_READ_ONLY" = "yes" ]; then
> > -[ "$VERBOSE" != "no" ] && echo "udev-cache: read-only rootfs, skip 
> > generating udev-cache"
> > -exit 0
> > -fi
> > -
> > -if [ "$DEVCACHE" != "" -a -e /dev/shm/udev.cache ]; then
> > -   echo "Populating dev cache"
> > -   tar --directory=/ --selinux --xattrs -cf "$DEVCACHE" dev
> > -   mv /dev/shm/udev.cache /etc/udev/cache.data
> > -fi
> > -
> > -exit 0
> > diff --git a/recipes-core/udev/udev_182.bbappend 
> > b/recipes-core/udev/udev_182.bbappend
> > deleted file mode 100644
> > index 6f8f049..000
> > --- a/recipes-core/udev/udev_182.bbappend
> > +++ /dev/null
> > @@ -1,5 +0,0 @@
> > -PR .= ".4"
> > -
> > -FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > -
> > -inherit with-selinux
> > 
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux] git recipes

[Joe MacDonald]

[Re: [yocto] [meta-selinux] git recipes] On 16.02.29 (Mon 08:06) Mark Hatle 
wrote:

> On 2/27/16 10:23 PM, Philip Tricca wrote:
> > Adding a sensible subject.
> 
> Sorry couldn't reply when I saw this when you first sent it.  Corporate email
> server went down for those of us who DON'T use outlook.. argh..
> 
> Anyway..
> 
> What I'm generally used to in the Yocto Project work is that the 'git' version
> picks a specific git snapshot and makes it a quick operation for someone to
> arbitrarily change that snapshot by adjusting the SRCREV.

This has been the approach I'd always tried to take with _git recipes as
well and it tends to work very well for ones that are either the only or
the preferred recipe.  I think in our case we were always preferring the
released versions for several historical reasons and the _git recipes were
relegated to the second-tier because of it.  But that means that basically
they never got updated.

About a year and a half ago I started seriously talking about dumping the
userspace tools entirely and only ever working out of the _git recipes.
Shrikant started doing that work after I discussed it with him but we
never got beyond the policy recipes.  So if you guys think this is not a
completely insane thing to do, that's the direction I'd like to go with
this.

> We don't use the AUTOREV parameter, because that causes the system to have to 
> do
> a git pull in order to evaluate the available versions and determine the 
> SRCREV
> to use.  So it's all down to a parsing and performance issue.

And avoiding surprises on the other side of the bathtub curve, when
updates pop up that we aren't prepared for.  :-)  But we've been behind
on developments aging out, too, so I don't have a strong case to argue
against AUTOREV.

> What I've done on some of my own projects is have an AUTOREV version 
> (locally),
> then when it triggers a recipe breakage, I think update the SRCREV and fix it 
> in
> the remote tree..  so I get the autorev, the world gets a version of the 
> package
> that keeps working.  (I also update the SRCREV other times as well.. but the
> autorev breakage is one of the key triggers.)
> 
> Joe might have some suggestions as well, I'm not against AUTOREV per say, but 
> I
> am worried about any performance issues during the parse.

I would really rather avoid AUTOREV, but I think the way we would
accomplish that is to edge away from our current recipes and bring the
_git ones back to centre stage.  Then we're likely to stay on top of a
fixed SRCREV anyway.

But as I say, maybe I'm completely insane on this point.

-J.

> 
> --Mark
> 
> > On 02/27/2016 08:17 PM, Philip Tricca wrote:
> >> While going through the backlog I ran across the 'git' versions of the
> >> user space. I noticed that a recent contribution was adding a patch to
> >> the git recipe and I figured that this patch would already be upstream
> >> and so wouldn't be necessary. Not so. The 'git' versions have SRCREV
> >> hard wired (SRCREV) to a commit id but it's way back from the end of
> >> 2013. They're also disabled via DEFAULT_PREFERENCE = "-1"
> >>
> >> These 'git' versions seem super useful for testing bleeding edge stuff
> >> so IMHO keeping them around would be the right thing to do. Not sure how
> >> I feel about them tracking an ancient commit though. Since they're never
> >> built by default it seems reasonable to track the master branch.
> >>
> >> What's our philosophy w/r to recipes that pull from git? Is there some
> >> history behind this SRCREV?
> >>
> >> Thanks,
> >> Philip
> >>
> > 
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [autobuilder][PATCH] CreateBBLayersConf: optionally exclude repos from default bblayers.conf

[Joe MacDonald]

When a repo is listed in the autobuilder config file, it is automatically
included in the resulting bblayers.conf.  In most scenarios this is the
correct thing to do, however it results in a build error if a layer such
as meta-openembedded is one of the listed repos:

  IOError: [Errno 2] file [...]/build/meta-openembedded/conf/layer.conf not 
found

since meta-openembedded does not contain a top-level conf/ tree and is not
intended to be included as a meta-* layer itself.

Add an 'autoinclude' flag to the 'repo:' stanza of the config file with
the default being 'True' (ie. the current behaviour) but when set to
'False' the layer will still be checked out (making this behaviour
distinct from the 'checkout' flag) but not included in the bblayer.conf by
default, only layers specifically referenced in the CreateBBLayersConf
section of the 'steps:' stanza will be included.

Signed-off-by: Joe MacDonald 
---
 .../site-packages/autobuilder/buildsteps/CreateBBLayersConf.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateBBLayersConf.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateBBLayersConf.py
index 03cb2a1..ace9fbb 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateBBLayersConf.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateBBLayersConf.py
@@ -95,7 +95,8 @@ class CreateBBLayersConf(ShellCommand):
 elif layer.iterkeys().next()=="meta-qt4":
 if layerversioncore is not None and 
int(layerversioncore) > 6:
 fout = fout + workdir + '/build/' + 
layer.iterkeys().next() + ' \ \n'
-else:
+elif 
(layer[layer.iterkeys().next()].has_key('autoinclude') and 
layer[layer.iterkeys().next()]['autoinclude'] is not False) or \
+ 
layer[layer.iterkeys().next()].has_key('autoinclude') is False:
 fout = fout + workdir + '/build/' + 
layer.iterkeys().next() + ' \ \n'
 ldirs.append(layer.iterkeys().next())
 
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] swig is in meta-oe, remove this copy

[Joe MacDonald]

[Re: [yocto] [meta-selinux][PATCH] swig is in meta-oe, remove this copy] On 
16.02.22 (Mon 15:58) Burton, Ross wrote:

> 
> On 22 February 2016 at 15:33, Joe MacDonald  wrote:
> 
> I'm also not against removing the local copy (I don't think it adds
> anything to the layer and occasionally causes headaches), but I really
> don't want to make meta-selinux dependent on meta-oe components, so I
> guess I'm voting for keeping it.
> 
> 
> Luckily it's also in oe-core (meta/recipes-devtools/swig/swig_3.0.8.bb).

And, y'know what?  I thought I'd had this very conversation with Armin
regarding it being in meta-security ages back, but since swig was still
in meta-selinux and Radzy mentioned it's also still in meta-oe, I
assumed it must've been some other package duplicated between
meta-selinux and meta-security (libcap-ng, perhaps?).

So with that, let's say my only concern no longer applies.  :-)

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] swig is in meta-oe, remove this copy

[Joe MacDonald]

nfiguring easier, check for a locally built PCRE using the 
> > Tools/pcre-build.sh script
> > - if test x"${with_pcre}" = xyes ; then 
> > --  AC_MSG_CHECKING([whether to use local PCRE])
> > --  local_pcre_config=no
> > --  if test -z $PCRE_CONFIG; then
> > --if test -f `pwd`/pcre/pcre-swig-install/bin/pcre-config; then
> > --  PCRE_CONFIG=`pwd`/pcre/pcre-swig-install/bin/pcre-config
> > --  local_pcre_config=$PCRE_CONFIG
> > --fi
> > --  fi
> > --  AC_MSG_RESULT([$local_pcre_config])
> > --fi
> > --AS_IF([test "x$with_pcre" != xno],
> > --  [AX_PATH_GENERIC([pcre],
> > --[], dnl Minimal version of PCRE we need -- accept any
> > --[], dnl custom sed script for version parsing is not needed
> > --[AC_DEFINE([HAVE_PCRE], [1], [Define if you have PCRE library])
> > -- LIBS="$LIBS $PCRE_LIBS"
> > -- CPPFLAGS="$CPPFLAGS $PCRE_CFLAGS"
> > --],
> > --[AC_MSG_FAILURE([
> > --Cannot find pcre-config script from PCRE (Perl Compatible Regular 
> > Expressions)
> > --library package. This dependency is needed for configure to 
> > complete,
> > --Either:
> > --- Install the PCRE developer package on your system (preferred 
> > approach).
> > --- Download the PCRE source tarball, build and install on your 
> > system
> > --  as you would for any package built from source distribution.
> > --- Use the Tools/pcre-build.sh script to build PCRE just for SWIG 
> > to statically
> > --  link against. Run 'Tools/pcre-build.sh --help' for instructions.
> > --  (quite easy and does not require privileges to install PCRE on 
> > your system)
> > --- Use configure --without-pcre to disable regular expressions 
> > support in SWIG
> > --  (not recommended).])
> > --])
> > -+  PKG_CHECK_MODULES([PCRE], [libpcre], [
> > -+AC_DEFINE([HAVE_PCRE], [1], [Define if you have PCRE library])
> > -+LIBS="$LIBS $PCRE_LIBS"
> > -+CPPFLAGS="$CPPFLAGS $PCRE_CFLAGS"
> > -+  ], [
> > -+AC_MSG_WARN([$PCRE_PKG_ERRORS])
> > -   ])
> > --
> > -+fi
> > - 
> > - dnl CCache
> > - AC_ARG_ENABLE([ccache], AS_HELP_STRING([--disable-ccache], [disable 
> > building and installation of ccache-swig executable (default enabled)]), 
> > [enable_ccache=$enableval], [enable_ccache=yes])
> > --- 
> > -1.7.9.5
> > -
> > diff --git a/recipes-devtools/swig/swig_2.0.10.bb 
> > b/recipes-devtools/swig/swig_2.0.10.bb
> > deleted file mode 100644
> > index 5f1ff5992359..
> > --- a/recipes-devtools/swig/swig_2.0.10.bb
> > +++ /dev/null
> > @@ -1,11 +0,0 @@
> > -require ${BPN}.inc
> > -
> > -PR = "${INC_PR}.0"
> > -
> > -SRC_URI += 
> > "file://0001-Use-proc-self-exe-for-swig-swiglib-on-non-Win32-plat.patch \
> > -file://0001-configure-use-pkg-config-for-pcre-detection.patch \
> > -   "
> > -
> > -SRC_URI[md5sum] = "6d5e7ad05b4a404e5e85db9befb70c9a"
> > -SRC_URI[sha256sum] = 
> > "d1eef329e867124ce60838b5ad07c763146b6c8f250dd22a861ead7406f78e63"
> > -
> > 
> 

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] MAINTAINERS: Update maintainers file

[Joe MacDonald]

[Re: [yocto] [meta-selinux][PATCH] MAINTAINERS: Update maintainers file] On 
16.02.20 (Sat 20:24) Philip Tricca wrote:

> On 02/17/2016 06:41 PM, Joe MacDonald wrote:
> > Adding Philip Tricca as a common layer maintainer and marking Pascal as
> > away.
> 
> While the admins upstream get my ssh key in place I did a pass over the
> pending patches and the current state of the repo. There isn't a lot to
> do in the actual meta-selinux layer beyond what's already on the list.
> There was only one fix needed to get the build working again:
> 
> The xattr patches to e2fsprogs have been superseded by the work that
> WindRiver has been doing in upstream e2fsprogs. There's a bug in their
> implementation though and the root directory on the rootfs image doesn't
> get labeled. I've sent a fix to the upstream maintainer. In the meantime
> the current patches can just be dropped and replaced with this one.
> 
> There's also one fix required to get a login shell working. In
> openembedded-core, commit
> http://git.openembedded.org/openembedded-core/commit/?id=b93369a7943949f51057e0a704f5524ab7682fe6
> breaks the login process when the SELinux policy is enforced. I've sent
> a patch upstream to fix this:
> http://article.gmane.org/gmane.comp.handhelds.openembedded.core/76599
> 
> When I can commit these changes they're ready to go. After that I'll do
> another pass over the list and pick up the remaining patches that
> weren't required to get basic functionality back.

Awesome, thanks Philip.  I've pushed the change to the repo this morning
that lists you in the maintainers file, but if you haven't got access yet
to push to the repo yourself I'll be happy to take a PR from  you and
merge it myself.  I think I'm finally getting my head above water today.

Also, Michael, we talked last summer about getting meta-selinux added to
the list of projects monitored by Patchwork at patchwork.openembedded.org
and everyone seemed in favour of it but we didn't seem to close the loop
on it.  What's needed from Philip / Mark / myself to make that happen?

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] MAINTAINERS: Update maintainers file

[Joe MacDonald]

Adding Philip Tricca as a common layer maintainer and marking Pascal as
away.

Signed-off-by: Joe MacDonald 
---
 MAINTAINERS | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Pascal:  if you're still watching the list, it looks like your email is
bouncing, can you contact either Mark or myself so we can update your contact
info if you're still able to / interested in acting as a maintainer?

Also, if someone else has an alternative contact for Pascal (Xin) please send
him a ping for us.  Thanks all.

diff --git a/MAINTAINERS b/MAINTAINERS
index b228e21..3c49548 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -24,7 +24,12 @@ F:   conf
 F: classes
 F: recipes-*
 
-M: Xin Ouyang 
+M: Philip Tricca 
+F: conf
+F: classes
+F: recipes-*
+
+M: (away) Xin Ouyang 
 F: conf
 F: classes
 F: recipes-*
-- 
2.1.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] To fix ERROR: No recipes available for: /home/tperrot/dev/oe-build-easy/combination/meta-selinux/recipes-extended/net-tools/net-tools_1.60-25.bbappend The version of

[Joe MacDonald]

Hi Thomas,

Thanks for the update, but I had already sent out a patch for review for
this yesterday:

https://www.mail-archive.com/yocto@yoctoproject.org/msg25655.html

since it's obviously a blocking issue for anyone building meta-selinux
now, I've merged and pushed it.

-J.

[[yocto] [meta-selinux][PATCH] To fix ERROR: No recipes available for: 
/home/tperrot/dev/oe-build-easy/combination/meta-selinux/recipes-extended/net-tools/net-tools_1.60-25.bbappend
 The version of the recipe has changed to 1.60-26 in openembedded-core.] 
> Signed-off-by: Thomas Perrot 
> ---
>  .../net-tools/{net-tools_1.60-25.bbappend => net-tools_1.60-%.bbappend}   | 0
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  rename recipes-extended/net-tools/{net-tools_1.60-25.bbappend => 
> net-tools_1.60-%.bbappend} (100%)
> 
> diff --git a/recipes-extended/net-tools/net-tools_1.60-25.bbappend 
> b/recipes-extended/net-tools/net-tools_1.60-%.bbappend
> similarity index 100%
> rename from recipes-extended/net-tools/net-tools_1.60-25.bbappend
> rename to recipes-extended/net-tools/net-tools_1.60-%.bbappend
> -- 
> 2.1.4
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] net-tools: update bbappend for new base recipe

[Joe MacDonald]

Commit bf362e4a8bb9fef3d16b81dea7b39a057e293ee4 in poky updates net-tools,
take this opportunity to convert this to a wildcard, since the bbappend
still seems to apply.

Signed-off-by: Joe MacDonald 
---
 recipes-extended/net-tools/net-tools_%.bbappend   | 11 +++
 recipes-extended/net-tools/net-tools_1.60-25.bbappend | 11 ---
 2 files changed, 11 insertions(+), 11 deletions(-)
 create mode 100644 recipes-extended/net-tools/net-tools_%.bbappend
 delete mode 100644 recipes-extended/net-tools/net-tools_1.60-25.bbappend

diff --git a/recipes-extended/net-tools/net-tools_%.bbappend 
b/recipes-extended/net-tools/net-tools_%.bbappend
new file mode 100644
index 000..e99a5bc
--- /dev/null
+++ b/recipes-extended/net-tools/net-tools_%.bbappend
@@ -0,0 +1,11 @@
+PR .= ".2"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+SRC_URI += "file://netstat-selinux-support.patch"
+
+inherit selinux
+
+DEPENDS += "${LIBSELINUX}"
+
+EXTRA_OEMAKE += "${@target_selinux(d, 'HAVE_SELINUX=1', 'HAVE_SELINUX=0')}"
diff --git a/recipes-extended/net-tools/net-tools_1.60-25.bbappend 
b/recipes-extended/net-tools/net-tools_1.60-25.bbappend
deleted file mode 100644
index e99a5bc..000
--- a/recipes-extended/net-tools/net-tools_1.60-25.bbappend
+++ /dev/null
@@ -1,11 +0,0 @@
-PR .= ".2"
-
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-SRC_URI += "file://netstat-selinux-support.patch"
-
-inherit selinux
-
-DEPENDS += "${LIBSELINUX}"
-
-EXTRA_OEMAKE += "${@target_selinux(d, 'HAVE_SELINUX=1', 'HAVE_SELINUX=0')}"
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCHv2 6/8] e2fsprogs: Copy xattr block from source file.

[Joe MacDonald]

fix = xattr_find_prefix (name_curr, name_length);
> >>>> ++   if (!prefix) {
> >>>> ++   fprintf (stderr, "Don't currently handle xattr: 
> >>>> %s\n", name_curr);
> >>>> ++   continue;
> >>>> ++   }
> >>>> ++   value = xattr_get_value (path, name_curr, 
> >>>> &value_length);
> >>>> ++   if (value == NULL) {
> >>>> ++   // no xattr value or error
> >>>> ++   fprintf (stderr, "failed to get value, 
> >>>> skipping\n");
> >>>> ++   goto next;
> >>>> ++   }
> >>>> ++       /* setup offsets and lengths for name and value */
> >>>> ++   entry->e_name_len = name_length - prefix->length;
> >>>> ++   entry->e_name_index = prefix->index;
> >>>> ++   /* Can't know these till we know the length of the 
> >>>> value. */
> >>>> ++   entry->e_value_offs = value_index -= 
> >>>> EXT2_EXT_ATTR_SIZE(value_length);
> >>>> ++   entry->e_value_size = value_length;
> >>>> ++   /* Check to be sure entry name and value don't overlap 
> >>>> before copy. */
> >>>> ++   if (EXT2_EXT_ATTR_NAME(entry) + entry->e_name_len > 
> >>>> VALUE(*header, entry)) {
> >>>> ++   fprintf (stderr, "xattr entry name and value 
> >>>> overlap! Too much xattr data.");
> >>>> ++   ret = -1;
> >>>> ++   goto out;
> >>>> ++   }
> >>>> ++   /* copy name and value data then calculate the hash */
> >>>> ++   memcpy (EXT2_EXT_ATTR_NAME(entry),
> >>>> ++   name_curr + prefix->length,
> >>>> ++   entry->e_name_len);
> >>>> ++   memcpy (VALUE(*header, entry), value, 
> >>>> entry->e_value_size);
> >>>> ++   entry->e_hash = ext2fs_ext_attr_hash_entry (entry, 
> >>>> VALUE(*header,
> >>>> ++entry));
> >>>> ++next:
> >>>> ++   if (value)
> >>>> ++   free (value);
> >>>> ++   }
> >>>> ++   XATTR_STDERR ("xattr_build_block: done building xattr 
> >>>> buffer\n");
> >>>> ++out:
> >>>> ++   if (names)
> >>>> ++   free (names);
> >>>> ++   return ret;
> >>>> ++}
> >>>> ++
> >>>> + /* This is the entry point to the xattr module. This function
> >>>> +copies the xattrs
> >>>> +  * from the file at 'path' to the file system object at 'ino'.
> >>>> +  *
> >>>> +@@ -28,7 +272,56 @@ errcode_t
> >>>> + set_inode_xattr (ext2_filsys fs, ext2_ino_t ino, const char *path)  {
> >>>> +errcode_t ret = 0;
> >>>> ++   char *buf = NULL;
> >>>> ++   struct ext2_inode inode = { 0 };
> >>>> ++   blk_t block = 0;
> >>>> ++   struct ext2_ext_attr_header *header = NULL;
> >>>> ++   uint32_t newcount = 0;
> >>>> +
> >>>> +XATTR_STDERR ("Copying xattrs from %s to inode 0x%x.\n", path,
> >>>> + ino);
> >>>> ++   /* Populate the xattr block for the file at path */
> >>>> ++   if (ret = xattr_build_block (path, &header, fs->blocksize)) {
> >>>> ++   goto out;
> >>>> ++   }
> >>>> ++   if (header == NULL) {
> >>>> ++   XATTR_STDERR ("set_inode_xattrs: no xattrs for %s\n", 
> >>>> path);
> >>>> ++   goto out;
> >>>> ++   }
> >>>> ++   if (ret = ext2fs_read_inode (fs, ino, &inode)) {
> >>>> ++   com_err(__func__, ret, "ext2fs_read_inode");
> >>>> ++   goto out;
> >>>> ++   }
> >>>> ++   if (ret = ext2fs_alloc_block (fs, 0, NULL, &block)) {
> >>>> ++   com_err(__func__, ret, "ext2fs_alloc_block: returned 
> >>>> %d", ret);
> >>>> ++   goto out;
> >>>> ++   }
> >>>> ++   ext2fs_mark_block_bitmap2 (fs->block_map, block);
> >>>> ++   XATTR_STDERR ("writing xattr block 0x%x to disk:\n", block);
> >>>> ++   if (ret = ext2fs_write_ext_attr (fs, block, header)) {
> >>>> ++   com_err(__func__, ret, "ext2fs_write_ext_attr: returned 
> >>>> %d", ret);
> >>>> ++   goto out;
> >>>> ++   }
> >>>> ++   /* point inode for current file to xattr block, update block 
> >>>> count and
> >>>> ++* write inode to disk
> >>>> ++*/
> >>>> ++   inode.i_file_acl = block;
> >>>> ++   if (ret = ext2fs_adjust_ea_refcount2(fs,
> >>>> ++   block,
> >>>> ++   (char*)header,
> >>>> ++   1,
> >>>> ++   &newcount))
> >>>> ++   {
> >>>> ++   com_err(__func__, ret, "ext2fs_adjust_ea_refcount");
> >>>> ++   goto out;
> >>>> ++   }
> >>>> ++   if (ret = ext2fs_iblk_add_blocks (fs, &inode, 1)) {
> >>>> ++   com_err(__func__, ret, "ext2fs_iblk_add_blocks failed");
> >>>> ++   goto out;
> >>>> ++   }
> >>>> ++   if (ret = ext2fs_write_inode (fs, ino, &inode))
> >>>> ++   com_err(__func__, ret, "ext2fs_write_inode: returned 
> >>>> %d", ret);
> >>>> ++out:
> >>>> ++   if (header)
> >>>> ++   free (header);
> >>>> +return ret;
> >>>> + }
> >>>> diff --git a/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bbappend
> >>>> b/recipes- devtools/e2fsprogs/e2fsprogs_1.42.9.bbappend
> >>>> index a4576b1..edc94d8 100644
> >>>> --- a/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bbappend
> >>>> +++ b/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bbappend
> >>>> @@ -4,4 +4,5 @@ SRC_URI += " \
> >>>>  file://misc-xattr-add-xattr-module-stub.patch \
> >>>>  file://mke2fs.c-create_inode.c-copy-xattrs.patch \
> >>>>  file://lib-ext2fs-ext2_ext_attr.h-add-xattr-index.patch \
> >>>> +file://misc-xattr-create-xattr-block.patch \
> >>>>  "
> >>>> --
> >>>> 2.1.4
> >>>>
> >>>> --
> >>>> ___
> >>>> yocto mailing list
> >>>> yocto@yoctoproject.org
> >>>> https://lists.yoctoproject.org/listinfo/yocto
> > 
> 

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-cgl][PATCH] README: updated maintainers and general content accordingly

[Joe MacDonald]

Acked-by: Joe MacDonald 

[[meta-cgl][PATCH] README: updated maintainers and general content accordingly] 
On 15.08.25 (Tue 14:00) Alexandru.Vaduva wrote:

> Signed-off-by: Alexandru.Vaduva 
> 
> Author:Alexandru.Vaduva 
> Signed-off-by: Alexandru.Vaduva 
> ---
>  README | 24 
>  1 file changed, 8 insertions(+), 16 deletions(-)
> 
> diff --git a/README b/README
> index d25fb0b..9f6713c 100644
> --- a/README
> +++ b/README
> @@ -44,7 +44,10 @@ http://git.yoctoproject.org/git/meta-cgl
>  Maintenance
>  ===
>  
> -Maintainers: Enea Linux Team 
> +Maintainers:
> +Adrian Dudau 
> +Alexandru Vaduva 
> +Joe MacDonald 
>  
>  
>  Contributing
> @@ -61,6 +64,7 @@ here: 
> https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
>  example:
>  git send-email -1 -M --to yocto@yoctoproject.org  
> --subject-prefix=meta-cgl][PATCH
>  
> +
>  Table of Contents
>  =
>  
> @@ -84,12 +88,13 @@ other layers needed. Adapt the below list to proper 
> format.
>BBLAYERS:
>  
>  meta
> -meta-cgl
> +meta-cgl/meta-cgl-common
>  meta-qt3
>  meta-openembedded/meta-networking
>  meta-openembedded/meta-filesystems
>  meta-openembedded/meta-oe
>  meta-openembedded/meta-perl
> +meta-openembedded/meta-python
>  meta-yocto
>  meta-yocto-bsp
>  meta-virtualization
> @@ -105,6 +110,7 @@ Now there is available the "cgl-init-build-env" script 
> which could be used to
>  automize the above mentione information:
>  ./scripts/cgl-checkout -b master -l meta-fsl-ppc
>  
> +
>  II. Misc
>  
>  
> @@ -139,17 +145,3 @@ or programming language operations required in the 
> application system at
>  a later stage.
>  Interface - shared boundary or connection between two dissimilar
>  objects, devices or systems.
> -
> -Users of this layer might experience a problem with openipmi package, if 
> this happens then this
> -package can be removed from packagegroup-cgl-middleware.bb package group and 
> exclude it from the
> -image used for building a CGL compliant image.
> -The latest tested head for the depending layers were:
> -poky:   bb00d83675a1293ee8d7a3ac22cf01243fa2397b
> -meta-cloud-services:a06e28ced8f622dbe6d6fbd9bea20b215d8ac938
> -meta-openclovis:83b1f76a75266743dc9eb0238039d5b973ad8ac0
> -meta-qt3:   3016129d90b7ac8517a5227d819f10ad417b5b45
> -meta-security:  b3f08c7b2bdf1bea28b081319d7c135af45f39e3
> -meta-selinux:   1699b56fd801f0194b708b4a1d9d95a831a3bbe4
> -meta-virtualization:    b94455174264240bf8519e4148ea5f1fb38d55c6
> -The machine for which this layer was tested are: 'qemuppc' and 
> 'p2020rdb'. The latest tested head
> -for meta-fsl-ppc layer is:  d953212ae5936a7d969d13801b0c2c1eb65cee6f
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [oe] [meta-selinux] Re: meta-selinux updates for oe-core-1.9 -- resend to right list.

[Joe MacDonald]

[[oe] [meta-selinux] Re: meta-selinux updates for oe-core-1.9 -- resend to 
right list.] On 15.08.13 (Thu 17:37) Randy MacLeod wrote:

> 
> Resending to the right list.
> (yocto@yoctoproject.org rather than
>  openembedded-de...@lists.openembedded.org )
> 
> Radzy will be working on meta-selinux and
> I've suggested that the start with a package uprev or two
> once the upstream selinux release intentions are known.

Well, the backlog is cleared out (not quite true, but I'm waiting on a
final verification from my autobuilders before merging the last couple
of patches) and it looks like I didn't destroy Phil's work on the
filesystem labelling bits when rebasing them, so I expect I'll merge
those tomorrow too.  Let's say everything after that is negotiable.  :-)

-J.

> 
> ../Randy
> 
> ---
> 
> Going on-list like I should have originally.
> 
> On 2015-07-31 01:33 PM, Joe MacDonald wrote:
> >Hey Randy,
> >
> >Good to hear from you.
> >
> >[meta-selinux updates for oe-core-1.9] On 15.07.31 (Fri 01:05) Randy MacLeod 
> >wrote:
> >
> >>What's the plan for meta-selinux in the next 2 months?
> 
> Roy dug up the current meta-selinux, upstream versions:
> 
> swig 2.0.103.0.6
> python-ipy 0.81 0.83
> audit 2.3.22.4.3
> refpolicy-mls 2.201403112.20141203
> libcap-ng 0.7.30.7.7
> setools   3.3.83.3.8
> sepolgengit1.2.2
> libsemanage git  2.4
> checkpolicy 2.3  2.4
> policycoreutils git  2.4
> selinux-config  0.1  0.1
> libsepolgit  2.4
> libsemanage 2.3  2.4
> sepolgen  1.2.11.2.2
> libsepol2.3  2.4
> libselinux  git  2.4
> policycoreutils 2.3  2.4
> libselinux  2.3  2.4
> ustr  1.0.41.0.4
> 
> 
> >
> >There's a backlog of meta-selinux patches to integrate that have been in
> >my merge queue for rather a long time now.  I expect to clear that out,
> >which will include an update to the most recent (not the current, any
> >longer, I don't think) refpolicy and a new recipe that will build from
> >the refpolicy git repository rather than release tarballs.  I think
> >this'll be a significant benefit to everyone in that it'll make it much
> >easier to migrate patches and to try out a new release without waiting
> >for a full update.  Those are the big things on the horizon.
> >
> >The other one is the filesystem labelling work being done by the
> >community.  It looks quite good and as soon as I get a few minutes to
> >try it out a bit more on some oddball configurations to ensure we aren't
> >bringing in any new dependencies (after having just scrubbed a bunch of
> >bashisms and hidden deps), it'll likely get merged.
> >
> >There's nothing on the radar in the short term that hasn't already been
> >discussed on the mailing list, though, AFAIK.
> >
> >-J.
> 
> So when Radzy is back in a week from being OOO, hopefully Joe's backlog
> will be cleared and we all can update pkgs as needed. We can split
> up that work however it makes sense; just tell the list
> if you start working on a package.
> 
> My quick review of git logs and my memory of selinux releases
> tells me that there tends to be an late fall release.
> I looked at the Changelog for a few of the components of:
> https://github.com/SELinuxProject/selinux
> and things seem to be moving along more quickly than usual
> so that pattern might not hold. Is anyone subscribed to the list:
> https://www.nsa.gov/research/selinux/list.shtml
> if so is there talk of an approximate release date that
> would help us decide if we went to update now or in a month or so?
> 
> Oh and is selinux happy under gcc-5.2+?
> 
> ../Randy
> 
> 
> >
> >>
> >>Roy can you summarize the state of each recipe?
> >>i.e. current version and upstream version?
> >>I'd like to make sure that we're up to date when
> >>oe-core-1.9 is released.
> >>
> 
> 
> -- 
> # Randy MacLeod. SMTS, Linux, Wind River
> Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada,
> K2K 2W5
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux] How about remove libcap-ng from meta-selinux?

[Joe MacDonald]

[[yocto] [meta-selinux] How about remove libcap-ng from meta-selinux?] On 
15.08.12 (Wed 17:08) wenzong fan wrote:

> Hi All,
> 
> There's a libcap-ng in meta-oe layer, it has been updated to 0.7.7 and the
> one in meta-selinux is 0.7.3.
> 
> How about removing the one in meta-selinux and get this layer depends on
> meta-oe? Any suggestions?

The last time we had this discussion my sense was that most users of
meta-selinux wanted to continue with it only depending on oe-core.
That's my preference as well.

I'm happy to merge an updated version of libcap-ng (or maybe I'll get to
it myself, since I've known about it since Armin removed it from
meta-security, that was the time of the last discussion, I think).

All I'm saying right now is that this isn't a case of accidental
duplication of recipes in multiple layers, it's the result of a
conscious decision.  It's totally worthwhile re-visiting that decision,
though to make sure the reasons are still valid.

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH v1] libpam: use wildcard for version and cleanup

[Joe MacDonald]

/pam_sepermit/Makefile.am
> > -+++ b/modules/pam_sepermit/Makefile.am
> > -@@ -35,7 +35,7 @@ if HAVE_LIBSELINUX
> > -   securelib_LTLIBRARIES = pam_sepermit.la <http://pam_sepermit.la>
> > -
> > - install-data-local:
> > --  mkdir -p $(sepermitlockdir)
> > -+  mkdir -p $(DESTDIR)$(sepermitlockdir)
> > - endif
> > - if ENABLE_REGENERATE_MAN
> > - noinst_DATA = README pam_sepermit.8 sepermit.conf.5
> > ---
> > -1.7.5.4
> > -
> > diff --git a/recipes-extended/pam/libpam_%.bbappend
> > b/recipes-extended/pam/libpam_%.bbappend
> > new file mode 100644
> > index 000..adcf938
> > --- /dev/null
> > +++ b/recipes-extended/pam/libpam_%.bbappend
> > @@ -0,0 +1,3 @@
> > +inherit enable-selinux
> > +
> > +RDEPENDS_${PN}-runtime += "${@target_selinux(d,
> 'pam-plugin-selinux')}"
> > diff --git a/recipes-extended/pam/libpam_1.1.6.bbappend
> > b/recipes-extended/pam/libpam_1.1.6.bbappend
> > deleted file mode 100644
> > index 71acecc..000
> > --- a/recipes-extended/pam/libpam_1.1.6.bbappend
> > +++ /dev/null
> > @@ -1,10 +0,0 @@
> > -#FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > -FILESPATH_append := ":${@base_set_filespath(['${THISDIR}/${PN}'],
> d)}"
> > -
> > -SRC_URI += "file://sepermit-add-DESTDIR-prefix.patch"
> > -
> > -PR .= ".4"
> > -
> > -inherit enable-selinux
> > -
> > -RDEPENDS_${PN}-runtime += "${@target_selinux(d,
> 'pam-plugin-selinux')}"
> > --
> > 1.7.9.5
> >
> >
> >
> >
> 
> 
> 

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCHv2 0/8] Label file system in build.

[Joe MacDonald]

: Add xattr security prefix data to
> lib/ext2fs/ext2_ext_attr.h
>   e2fsprogs: Copy xattr block from source file.
>   e2fsprogs: Add stub functions for an xattr cache and struct to hold
> the header and block data.
>   e2fsprogs: Implement xattr block cache with simple linked list.
> 
>  classes/selinux-image.bbclass  |   8 +
>  ...ib-ext2fs-ext2_ext_attr.h-add-xattr-index.patch |  20 ++
>  .../misc-xattr-add-xattr-module-stub.patch |  57 
>  .../misc-xattr-create-xattr-block-node.patch   | 175 +++
>  .../e2fsprogs/misc-xattr-create-xattr-block.patch  | 341 
> +
>  .../e2fsprogs/misc-xattr-create-xattr-cache.patch  | 181 +++
>  .../mke2fs.c-create_inode.c-copy-xattrs.patch  | 164 ++
>  .../e2fsprogs/e2fsprogs_1.42.9.bbappend|  10 +
>  .../images/core-image-selinux-minimal.bb   |   2 +-
>  recipes-security/images/core-image-selinux.bb  |   2 +-
>  .../policycoreutils-fts_flags-FTS_NOCHDIR.patch|  25 ++
>  recipes-security/selinux/policycoreutils_2.3.bb|   1 +
>  12 files changed, 984 insertions(+), 2 deletions(-)
>  create mode 100644 classes/selinux-image.bbclass
>  create mode 100644 
> recipes-devtools/e2fsprogs/e2fsprogs/lib-ext2fs-ext2_ext_attr.h-add-xattr-index.patch
>  create mode 100644 
> recipes-devtools/e2fsprogs/e2fsprogs/misc-xattr-add-xattr-module-stub.patch
>  create mode 100644 
> recipes-devtools/e2fsprogs/e2fsprogs/misc-xattr-create-xattr-block-node.patch
>  create mode 100644 
> recipes-devtools/e2fsprogs/e2fsprogs/misc-xattr-create-xattr-block.patch
>  create mode 100644 
> recipes-devtools/e2fsprogs/e2fsprogs/misc-xattr-create-xattr-cache.patch
>  create mode 100644 
> recipes-devtools/e2fsprogs/e2fsprogs/mke2fs.c-create_inode.c-copy-xattrs.patch
>  create mode 100644 recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bbappend
>  create mode 100644 
> recipes-security/selinux/policycoreutils/policycoreutils-fts_flags-FTS_NOCHDIR.patch
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-selinux] findutils/gnulib:drop the error output of 'ls' command

[Joe MacDonald]

[Re: [yocto] [PATCH][meta-selinux] findutils/gnulib:drop the error output of 
'ls' command] On 15.07.24 (Fri 16:51) wenzong fan wrote:

> Ping ...

This one clearly got lost in the mail somewhere (I'm working on making
sure that doesn't happen anymore) but it also doesn't look applicable to
the current findutils.  If it is, please re-submit it.

-J.

> 
> On 04/02/2015 10:26 AM, rongqing...@windriver.com wrote:
> >From: Roy Li 
> >
> >The ls command is used to check if the file exists, and it is normal that
> >the checked file does not exist, so drop the ls error ouput:
> >  ls: cannot access ./doc/fdl.texi: No such file or directory
> >
> >Signed-off-by: Roy Li 
> >---
> >  .../drop-the-error-output-of-ls-command.patch  | 29 
> > ++
> >  .../findutils/findutils_4.4.2.bbappend |  1 +
> >  2 files changed, 30 insertions(+)
> >  create mode 100644 
> > recipes-extended/findutils/findutils-4.4.2/drop-the-error-output-of-ls-command.patch
> >
> >diff --git 
> >a/recipes-extended/findutils/findutils-4.4.2/drop-the-error-output-of-ls-command.patch
> > 
> >b/recipes-extended/findutils/findutils-4.4.2/drop-the-error-output-of-ls-command.patch
> >new file mode 100644
> >index 000..069be41
> >--- /dev/null
> >+++ 
> >b/recipes-extended/findutils/findutils-4.4.2/drop-the-error-output-of-ls-command.patch
> >@@ -0,0 +1,29 @@
> >+[PATCH] drop the error output of 'ls' command
> >+
> >+Upstream-Status: pending
> >+
> >+ls is used to check if the file exists, and it is normal that
> >+the checked file does not exist, so drop the ls error
> >+ ls: cannot access ./doc/fdl.texi: No such file or directory
> >+
> >+Signed-off-by: Roy Li 
> >+---
> >+ gnulib-tool | 2 +-
> >+ 1 file changed, 1 insertion(+), 1 deletion(-)
> >+
> >+diff --git a/gnulib-tool b/gnulib-tool
> >+index 354b1f0..beb81ba 100755
> >+--- a/gnulib-tool
> > b/gnulib-tool
> >+@@ -602,7 +602,7 @@ else
> >+   {
> >+ # Use two sed invocations. A single sed -n -e 's,^.* -> \(.*\)$,\1,p'
> >+ # would do the wrong thing if the link target contains " -> ".
> >+-LC_ALL=C ls -l "$1" | sed -e 's, -> ,#%%#,' | sed -n -e 
> >'s,^.*#%%#\(.*\)$,\1,p'
> >++LC_ALL=C ls -l "$1" 2>/dev/null | sed -e 's, -> ,#%%#,' | sed -n -e 
> >'s,^.*#%%#\(.*\)$,\1,p'
> >+   }
> >+ fi
> >+
> >+--
> >+1.9.1
> >+
> >diff --git a/recipes-extended/findutils/findutils_4.4.2.bbappend 
> >b/recipes-extended/findutils/findutils_4.4.2.bbappend
> >index 3245e5c..e174888 100644
> >--- a/recipes-extended/findutils/findutils_4.4.2.bbappend
> >+++ b/recipes-extended/findutils/findutils_4.4.2.bbappend
> >@@ -5,6 +5,7 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
> >  SRC_URI += 
> > "git://git.savannah.gnu.org/gnulib.git;protocol=git;rev=0e0635af0b23826911dc456bd0da40dcb19247de"
> >  SRC_URI += "file://findutils-with-selinux.patch"
> >  SRC_URI += "file://findutils-with-selinux-gnulib.patch"
> >+SRC_URI += 
> >"file://drop-the-error-output-of-ls-command.patch;patchdir=../git/"
> >
> >  inherit with-selinux
> >
> >
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] python: use wildcard for verison

[Joe MacDonald]

I will, of course, actually spell-check the commit log before committing
anything.

-J.

[[yocto] [meta-selinux][PATCH] python: use wildcard for verison] On 15.02.25 
(Wed 10:13) Joe MacDonald wrote:

> The current python bbappend doesn't include any patches, so it's
> reasonable to move to a wildcard for the version.
> 
> Signed-off-by: Joe MacDonald 
> ---
>  recipes-devtools/python/{python_2.7.3.bbappend => python_%.bbappend} | 2 --
>  1 file changed, 2 deletions(-)
>  rename recipes-devtools/python/{python_2.7.3.bbappend => python_%.bbappend} 
> (92%)
> 
> diff --git a/recipes-devtools/python/python_2.7.3.bbappend 
> b/recipes-devtools/python/python_%.bbappend
> similarity index 92%
> rename from recipes-devtools/python/python_2.7.3.bbappend
> rename to recipes-devtools/python/python_%.bbappend
> index b8447e9..9eefd2d 100644
> --- a/recipes-devtools/python/python_2.7.3.bbappend
> +++ b/recipes-devtools/python/python_%.bbappend
> @@ -1,5 +1,3 @@
> -PR .= ".1"
> -
>  inherit selinux
>  # If selinux enabled, disable handlers to rw command history file
>  FILESEXTRAPATHS_prepend := "${@target_selinux(d, '${THISDIR}/${PN}:')}"
> -- 
> 1.9.1
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] python: use wildcard for verison

[Joe MacDonald]

The current python bbappend doesn't include any patches, so it's
reasonable to move to a wildcard for the version.

Signed-off-by: Joe MacDonald 
---
 recipes-devtools/python/{python_2.7.3.bbappend => python_%.bbappend} | 2 --
 1 file changed, 2 deletions(-)
 rename recipes-devtools/python/{python_2.7.3.bbappend => python_%.bbappend} 
(92%)

diff --git a/recipes-devtools/python/python_2.7.3.bbappend 
b/recipes-devtools/python/python_%.bbappend
similarity index 92%
rename from recipes-devtools/python/python_2.7.3.bbappend
rename to recipes-devtools/python/python_%.bbappend
index b8447e9..9eefd2d 100644
--- a/recipes-devtools/python/python_2.7.3.bbappend
+++ b/recipes-devtools/python/python_%.bbappend
@@ -1,5 +1,3 @@
-PR .= ".1"
-
 inherit selinux
 # If selinux enabled, disable handlers to rw command history file
 FILESEXTRAPATHS_prepend := "${@target_selinux(d, '${THISDIR}/${PN}:')}"
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend

[Joe MacDonald]

[[yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend] On 
15.02.25 (Wed 03:54) Robert P. J. Day wrote:

> 
>   minor quibble about kernel dev manual -- section 2.2.1, "creating
> the append file", uses the example of:
> 
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> 
> while section 2.2.3 uses:
> 
>  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> 
> both sections kind of implying that that's the way to do it, without
> making it clear that *either* way works as long as the variable
> prepend matches up with the directory name.
> 
>   both ways are correct, of course, but the wording is a bit
> confusing.

It's probably worth changing the latter reference to match the former.
Both work but with any new recipes (at least in the layers I maintain)
the preference is to use the former for clarity as well as faster
lookups.

-J.

> 
> rday
> 
> -- 
> 
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
> 
> Twitter:   http://twitter.com/rpjday
> LinkedIn:       http://ca.linkedin.com/in/rpjday
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] libpcap: add pkg-config support

[Joe MacDonald]

libpcap was not previously installing a pkg-config file.  Add a basic one
that will allow using 'pkg-config --libs libpcap', for example, in recipes
rather than 'pcap-config', which frequently returns incorrect information.

Signed-off-by: Joe MacDonald 
---

I'm not convinced that this is necessary, but when I tried to convert the ptpd
recipe in meta-networking to stop failing by using pcap-config it seems like
libpcap was never actually installing a reasonable .pc file.  The only other
example I could find in meta-networking switched from using pcap-config to an
internal pcap library, rather than using the oe-core version, so maybe it really
isn't working for anyone right now.  I created something that at least gets ptpd
to stop blowing up, but if there's a proper way to do this for ptpd, I'd be
happy to adopt that instead.

-J.

 meta/recipes-connectivity/libpcap/libpcap.inc  |  2 +-
 .../libpcap/libpcap-pkgconfig-support.patch| 71 ++
 meta/recipes-connectivity/libpcap/libpcap_1.6.2.bb |  6 +-
 3 files changed, 77 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-connectivity/libpcap/libpcap/libpcap-pkgconfig-support.patch

diff --git a/meta/recipes-connectivity/libpcap/libpcap.inc 
b/meta/recipes-connectivity/libpcap/libpcap.inc
index 979665c..0c608b5 100644
--- a/meta/recipes-connectivity/libpcap/libpcap.inc
+++ b/meta/recipes-connectivity/libpcap/libpcap.inc
@@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=1d4b0366557951c84a94fabe3529f867 \
 
file://pcap.h;beginline=1;endline=32;md5=39af3510e011f34b8872f120b1dc31d2"
 DEPENDS = "flex-native bison-native"
 
-inherit bluetooth
+inherit bluetooth pkgconfig
 
 PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 
'${BLUEZ}', '', d)}"
 PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4"
diff --git 
a/meta/recipes-connectivity/libpcap/libpcap/libpcap-pkgconfig-support.patch 
b/meta/recipes-connectivity/libpcap/libpcap/libpcap-pkgconfig-support.patch
new file mode 100644
index 000..9cfb9df
--- /dev/null
+++ b/meta/recipes-connectivity/libpcap/libpcap/libpcap-pkgconfig-support.patch
@@ -0,0 +1,71 @@
+From 8887132e85892a72a84ca3878e60f254ad2ce939 Mon Sep 17 00:00:00 2001
+From: Joe MacDonald 
+Date: Tue, 24 Feb 2015 15:56:06 -0500
+Subject: [PATCH] libpcap: pkgconfig support
+
+Adding basic structure to support pkg-config.
+
+Upstream-status: Inappropriate [embedded specific]
+
+Signed-off-by: Joe MacDonald 
+---
+ Makefile.in   |  5 +
+ configure.in  |  1 +
+ libpcap.pc.in | 10 ++
+ 3 files changed, 16 insertions(+)
+ create mode 100644 libpcap.pc.in
+
+diff --git a/Makefile.in b/Makefile.in
+index 1c2d745..1f25faf 100644
+--- a/Makefile.in
 b/Makefile.in
+@@ -60,6 +60,10 @@ V_RPATH_OPT = @V_RPATH_OPT@
+ DEPENDENCY_CFLAG = @DEPENDENCY_CFLAG@
+ PROG=libpcap
+ 
++# pkgconfig support
++pkgconfigdir = $(libdir)/pkgconfig
++pkgconfig_DATA = libpcap.pc
++
+ # Standard CFLAGS
+ FULL_CFLAGS = $(CCOPT) $(INCLS) $(DEFS) $(CFLAGS)
+ 
+@@ -275,6 +279,7 @@ EXTRA_DIST = \
+   lbl/os-solaris2.h \
+   lbl/os-sunos4.h \
+   lbl/os-ultrix4.h \
++  libpcap.pc \
+   missing/snprintf.c \
+   mkdep \
+   msdos/bin2c.c \
+diff --git a/configure.in b/configure.in
+index 8f5c86b..fb51b35 100644
+--- a/configure.in
 b/configure.in
+@@ -1700,6 +1700,7 @@ esac
+ AC_PROG_INSTALL
+ 
+ AC_CONFIG_HEADER(config.h)
++AC_CONFIG_FILES([libpcap.pc])
+ 
+ AC_OUTPUT_COMMANDS([if test -f .devel; then
+   echo timestamp > stamp-h
+diff --git a/libpcap.pc.in b/libpcap.pc.in
+new file mode 100644
+index 000..4f78ad8
+--- /dev/null
 b/libpcap.pc.in
+@@ -0,0 +1,10 @@
++prefix=@prefix@
++exec_prefix=@exec_prefix@
++libdir=@libdir@
++includedir=@includedir@
++
++Name: libpcap
++Description: System-independent interface for user-level packet capture.
++Version: @VERSION@
++Libs: -L${libdir} -lpcap
++Cflags: -I${includedir}
+-- 
+1.9.1
+
diff --git a/meta/recipes-connectivity/libpcap/libpcap_1.6.2.bb 
b/meta/recipes-connectivity/libpcap/libpcap_1.6.2.bb
index a2d5ef4..611543e 100644
--- a/meta/recipes-connectivity/libpcap/libpcap_1.6.2.bb
+++ b/meta/recipes-connectivity/libpcap/libpcap_1.6.2.bb
@@ -1,6 +1,8 @@
 require libpcap.inc
 
-SRC_URI += "file://aclocal.patch"
+SRC_URI += "file://aclocal.patch \
+file://libpcap-pkgconfig-support.patch \
+   "
 SRC_URI[md5sum] = "5f14191c1a684a75532c739c2c4059fa"
 SRC_URI[sha256sum] = 
"5db3e2998f1eeba2c76da55da5d474248fe19c44f49e15cac8a796a2c7e19690"
 
@@ -19,4 +21,6 @@ do_install_prepend () {
 install -d ${D}${bindir}
 oe_runmake install-shared DESTDIR=${D}
 oe_libinstall -a -so libpcap ${D}${libdir}
+sed "s|@VERSION@|${PV}|" -i ${B}/libpcap.pc
+install -D -m 0644 libpcap.pc 

[yocto] [meta-selinux][PATCH] policycoreutils: address QA issues

[Joe MacDonald]

Both the fixfiles and sandbox utilities had dependencies on bash when they
didn't really need to.  Update sandbox and patch fixfiles.  ifgen is
python script, so ensure that python is listed as a runtime dependency.

Signed-off-by: Joe MacDonald 
---
 recipes-security/selinux/policycoreutils.inc   |  7 +-
 .../policycoreutils-fixfiles-de-bashify.patch  | 92 ++
 .../policycoreutils-sandbox-de-bashify.patch   | 39 +
 3 files changed, 136 insertions(+), 2 deletions(-)
 create mode 100644 
recipes-security/selinux/policycoreutils/policycoreutils-fixfiles-de-bashify.patch
 create mode 100644 
recipes-security/selinux/policycoreutils/policycoreutils-sandbox-de-bashify.patch

diff --git a/recipes-security/selinux/policycoreutils.inc 
b/recipes-security/selinux/policycoreutils.inc
index 44a5861..4846683 100644
--- a/recipes-security/selinux/policycoreutils.inc
+++ b/recipes-security/selinux/policycoreutils.inc
@@ -7,7 +7,10 @@ context."
 SECTION = "base"
 LICENSE = "GPLv2+"
 
-SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', 
'', d)}"
+SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', 
'', d)} \
+file://policycoreutils-fixfiles-de-bashify.patch \
+file://policycoreutils-sandbox-de-bashify.patch \
+   "
 
 PAM_SRC_URI = "file://pam.d/newrole \
file://pam.d/run_init \
@@ -97,7 +100,7 @@ RDEPENDS_${BPN}-sepolicy += "\
 "
 # static link to libsepol
 DEPENDS_${BPN}-sepolgen-ifgen += "libsepol"
-RDEPENDS_${BPN}-sepolgen-ifgen += "libselinux-python"
+RDEPENDS_${BPN}-sepolgen-ifgen += "python libselinux-python"
 RDEPENDS_${BPN}-sestatus += "libselinux"
 RDEPENDS_${BPN}-setfiles += "\
libselinux \
diff --git 
a/recipes-security/selinux/policycoreutils/policycoreutils-fixfiles-de-bashify.patch
 
b/recipes-security/selinux/policycoreutils/policycoreutils-fixfiles-de-bashify.patch
new file mode 100644
index 000..44d7525
--- /dev/null
+++ 
b/recipes-security/selinux/policycoreutils/policycoreutils-fixfiles-de-bashify.patch
@@ -0,0 +1,92 @@
+From 25ca94680f2fe20f49b80e8b5b180a0dbb903f17 Mon Sep 17 00:00:00 2001
+From: Joe MacDonald 
+Date: Fri, 20 Feb 2015 17:00:19 -0500
+Subject: [PATCH] fixfiles: de-bashify
+
+Most of the bashisms in fixfiles are pretty easy to work around, the only
+complex one is the use of PIPESTATUS.  The common solution to this is to
+use fifos but considering the action this script is performing, that's not
+necessarily the best option here.  Introducing a second invocation of rpm
+is minimal overhead on an operation that should happen very infrequently,
+so we'll try that instead.
+
+Upstream-Status: Pending
+
+Signed-off-by: Joe MacDonald 
+---
+ scripts/fixfiles | 26 +++---
+ 1 file changed, 15 insertions(+), 11 deletions(-)
+
+diff --git a/scripts/fixfiles b/scripts/fixfiles
+index 5c29eb9..10a5078 100755
+--- a/scripts/fixfiles
 b/scripts/fixfiles
+@@ -1,4 +1,4 @@
+-#!/bin/bash
++#!/bin/sh
+ # fixfiles
+ #
+ # Script to restore labels on a SELinux box
+@@ -25,7 +25,7 @@
+ # number if the current kernel version is greater than 2.6.30, a negative
+ # number if the current is less than 2.6.30 and 0 if they are the same.
+ #
+-function useseclabel {
++useseclabel() {
+   VER=`uname -r`
+   SUP=2.6.30
+   expr '(' "$VER" : '\([^.]*\)' ')' '-' '(' "$SUP" : '\([^.]*\)' ')' '|' \
+@@ -91,9 +91,9 @@ exclude_dirs_from_relabelling() {
+ # skip not absolute path
+ # skip not directory
+ [ -z "${i}" ] && continue
+-[[ "${i}" =~ "^[[:blank:]]*#" ]] && continue
+-[[ ! "${i}" =~ ^/.* ]] && continue
+-[[ ! -d "${i}" ]] && continue
++echo "${i}" | egrep -q '^[[:space:]]*#' && continue
++echo "${i}" | egrep -v '^/.*' && continue
++[ ! -d "${i}" ] && continue
+ exclude_from_relabelling="$exclude_from_relabelling -e $i"
+ logit "skipping the directory $i"
+   done < /etc/selinux/fixfiles_exclude_dirs
+@@ -205,8 +205,12 @@ fi
+ }
+ 
+ rpmlist() {
+-rpm -q --qf '[%{FILESTATES} %{FILENAMES}\n]' "$1" | grep '^0 ' | cut -f2- -d 
' '
+-[ ${PIPESTATUS[0]} != 0 ] && echo "$1 not found" >/dev/stderr
++if rpm -q --qf '[%{FILESTATES} %{FILENAMES}\n]' "$1" >/dev/null
++then
++rpm -q --qf '[%{FILESTATES} %{FILENAMES}\n]' "$1" | grep '^0 ' | cut 
-f2- -d &

[yocto] [autobuilder][PATCH 1/2] config: support configuration templates

[Joe MacDonald]

Move yocto-controller and yocto-worker to .template versions and update
the setup script to move them in the expected location if they aren't
already preset, allowing local configurations to make whatever changes
they need in the yocto-[controller|worker] directories without issues on a
pull and without having to resort to tools like git-diff and git-checkout
to try alternate configurations.

Signed-off-by: Joe MacDonald 
---
 .gitignore |  15 ++---
 yocto-autobuilder-setup|  37 +
 .../Makefile   |   0
 .../buildbot.tac.example   |   0
 .../buildbot.tac.standard  |   0
 .../controller.cfg.example |   0
 .../public_html/bg_gradient.jpg| Bin
 .../public_html/default.css|   0
 .../public_html/favicon.ico| Bin
 .../public_html/robots.txt |   0
 .../templates/README.txt   |   0
 .../yoctoABConfig.py   |   0
 {yocto-worker => yocto-worker.template}/Makefile   |   0
 .../buildbot.tac.example   |   0
 14 files changed, 39 insertions(+), 13 deletions(-)
 rename {yocto-controller => yocto-controller.template}/Makefile (100%)
 rename {yocto-controller => yocto-controller.template}/buildbot.tac.example 
(100%)
 rename {yocto-controller => yocto-controller.template}/buildbot.tac.standard 
(100%)
 rename {yocto-controller => yocto-controller.template}/controller.cfg.example 
(100%)
 rename {yocto-controller => 
yocto-controller.template}/public_html/bg_gradient.jpg (100%)
 rename {yocto-controller => yocto-controller.template}/public_html/default.css 
(100%)
 rename {yocto-controller => yocto-controller.template}/public_html/favicon.ico 
(100%)
 rename {yocto-controller => yocto-controller.template}/public_html/robots.txt 
(100%)
 rename {yocto-controller => yocto-controller.template}/templates/README.txt 
(100%)
 rename {yocto-controller => yocto-controller.template}/yoctoABConfig.py (100%)
 rename {yocto-worker => yocto-worker.template}/Makefile (100%)
 rename {yocto-worker => yocto-worker.template}/buildbot.tac.example (100%)

diff --git a/.gitignore b/.gitignore
index a4b31c6..9a2db19 100644
--- a/.gitignore
+++ b/.gitignore
@@ -20,19 +20,8 @@ config/autobuilder.conf
 .cfg
 
 TODO
-yocto-controller/http.log
-yocto-controller/controller.cfg
-yocto-controller/state.sqlite
-yocto-controller/twistd.log*
-yocto-controller/buildbot.tac
-yocto-worker/build-appliance/build(newcommits)
-yocto-worker/buildbot.tac
-yocto-worker/janitor.log
-yocto-worker/nightly-x86/.buildbot-sourcedata-YnVpbGQ=
-yocto-worker/nightly/build(newcommits)
-yocto-worker/twistd.hostname
-yocto-worker/twistd.log*
-yocto-worker/twistd.pid
+yocto-controller
+yocto-worker
 
 # This gets updated on every yocto-setup-autobuilder so should be ignored #
 # for nearly everyone.#
diff --git a/yocto-autobuilder-setup b/yocto-autobuilder-setup
index 615deb4..8d447f7 100644
--- a/yocto-autobuilder-setup
+++ b/yocto-autobuilder-setup
@@ -62,6 +62,25 @@ export OGIT_TRASH_CRON_TIME="0 0 * * *"
 export OGIT_TRASH_NICE_LEVEL="19"
 HOST_ADDR=$(hostname -I)
 
+#
+#
+# Create a new controller/worker configuation based on our templates if we 
don't
+# already have one configured here.
+#
+#
+if [ ! -d "${PWD}/yocto-controller" ]; then
+echo ""
+echo "Creating yocto-controller/ from yocto-controller.template/"
+echo ""
+/bin/cp -R yocto-controller.template yocto-controller
+fi
+if [ ! -d "${PWD}/yocto-worker" ]; then
+echo ""
+echo "Creating yocto-worker/ from yocto-worker.template/"
+echo ""
+/bin/cp -R yocto-worker.template yocto-worker
+fi
+
 ##
 #
 # Check to see if we've got a username/password set
@@ -129,6 +148,24 @@ if [  ! -d  "./buildset-config" ]; then
 /bin/cp -R buildset-config.controller buildset-config
 fi
 
+#
+#
+# If there is already a state.sqlite file in the controller directory, it may
+# need upgrading.  Inform the user about this.  This command is run
+# automatically the first time it is run on a pristine configuration.  See
+# below.
+#
+#
+if [ -f ]; then
+echo ""
+echo "An existing yocto-controller/state.sqlite has been found."
+echo "If you have changed your configuration since the last time"
+echo "you sourced this setup script, you will most likely need to"
+echo "update it.  The command

[yocto] [autobuilder][PATCH 2/2] config: support external configurations

[Joe MacDonald]

It is sometimes convenient to have more than one configuration, either as
an alternative or as a parallel builder.  Support the ability to move
critical configuration components into a separate directory tree while
preserving the core yocto-autobuilder clone in a clean state.

The workflow is unchanged for the common use-case.  If you wish to have an
external (to the yocto-autobuilder tree) configuration, you may define
YOCTO_AB_CONFIG_DIR in your environment prior to sourcing
yocto-autobuilder-setup.  Something like this would work:

$ YOCTO_AB_CONFIG_DIR=/build/ab-new . ./yocto-autobuilder-setup

YOCTO_AB_CONFIG_DIR need not exist prior to sourcing the setup script, but
the parent directory must be writable.  If YOCTO_AB_CONFIG_DIR does
already exist, the setup script will attempt to re-use that directory.

Signed-off-by: Joe MacDonald 
---
 yocto-autobuilder-setup | 92 +++--
 yocto-start-autobuilder |  2 +-
 yocto-stop-autobuilder  |  2 +-
 3 files changed, 60 insertions(+), 36 deletions(-)

diff --git a/yocto-autobuilder-setup b/yocto-autobuilder-setup
index 8d447f7..24d420a 100644
--- a/yocto-autobuilder-setup
+++ b/yocto-autobuilder-setup
@@ -54,7 +54,8 @@ export ADTREPO_DEV_URL="http://adtrepo-dev.yoctoproject.org/";
 export ADTREPO_DEV_PATH="/srv/www/vhosts/adtrepo-dev/"
 export 
PYTHONPATH=`pwd`/lib/python2.7/site-packages/autobuilder/:`pwd`/lib/python2.7/site-packages/:`pwd`/lib/python2.7/site-packages/autobuilder/buildsteps:$PYTHONPATH
 export PATH=`pwd`/bin:`pwd`/yocto-autobuilder/scripts:$PATH
-export YOCTO_AB_CONFIG=`pwd`/buildset-config/yoctoAB.conf
+export 
YOCTO_AB_CONFIG=${YOCTO_AB_CONFIG_DIR:=`pwd`}/buildset-config/yoctoAB.conf
+export YOCTO_AB_CONFIG_DIR
 export RESOLVED_TRIGGERED_HEAD=True
 export OPTIMIZED_GIT_CLONE=False
 export OGIT_TRASH_DIR=/tmp/yocto-autobuilder/git/trash
@@ -64,21 +65,39 @@ HOST_ADDR=$(hostname -I)
 
 #
 #
+# Ensure the base config directory exists already
+#
+#
+if [ ! -d "${YOCTO_AB_CONFIG_DIR}" ]; then
+echo ""
+echo "${YOCTO_AB_CONFIG_DIR} does not exist"
+echo "attempting to create new autobuilder configuration"
+echo ""
+if ! /bin/mkdir -p ${YOCTO_AB_CONFIG_DIR} ; then
+echo "Unable to create ${YOCTO_AB_CONFIG_DIR}"
+echo "Ensure that you have the correct permissions and that you have"
+echo "specified YOCTO_AB_CONFIG_DIR correctly."
+exit
+fi
+fi
+
+#
+#
 # Create a new controller/worker configuation based on our templates if we 
don't
 # already have one configured here.
 #
 #
-if [ ! -d "${PWD}/yocto-controller" ]; then
+if [ ! -d "${YOCTO_AB_CONFIG_DIR}/yocto-controller" ]; then
 echo ""
 echo "Creating yocto-controller/ from yocto-controller.template/"
 echo ""
-/bin/cp -R yocto-controller.template yocto-controller
+/bin/cp -R yocto-controller.template 
${YOCTO_AB_CONFIG_DIR}/yocto-controller
 fi
-if [ ! -d "${PWD}/yocto-worker" ]; then
+if [ ! -d "${YOCTO_AB_CONFIG_DIR}/yocto-worker" ]; then
 echo ""
 echo "Creating yocto-worker/ from yocto-worker.template/"
 echo ""
-/bin/cp -R yocto-worker.template yocto-worker
+/bin/cp -R yocto-worker.template ${YOCTO_AB_CONFIG_DIR}/yocto-worker
 fi
 
 ##
@@ -86,30 +105,30 @@ fi
 # Check to see if we've got a username/password set
 #
 ##
-if [ ! -f  "${PWD}/yocto-controller/buildbot.tac" ]; then
+if [ ! -f  "${YOCTO_AB_CONFIG_DIR}/yocto-controller/buildbot.tac" ]; then
 echo ""
 echo "Creating yocto-controller/buildbot.tac from an example buildbot.tac"
 echo ""
-/bin/cp yocto-controller/buildbot.tac.example yocto-controller/buildbot.tac
+/bin/cp ${YOCTO_AB_CONFIG_DIR}/yocto-controller/buildbot.tac.example 
${YOCTO_AB_CONFIG_DIR}/yocto-controller/buildbot.tac
 fi
 
-if [ ! -f  "${PWD}/yocto-worker/buildbot.tac" ]; then
+if [ ! -f  "${YOCTO_AB_CONFIG_DIR}/yocto-worker/buildbot.tac" ]; then
 echo ""
 echo "Creating yocto-worker/buildbot.tac from an example buildbot.tac"
 echo ""
-/bin/cp yocto-worker/buildbot.tac.example yocto-worker/buildbot.tac
+/bin/cp ${YOCTO_AB_CONFIG_DIR}/yocto-worker/buildbot.tac.example 
${YOCTO_AB_CONFIG_DIR}/yocto-worker/buildbot.tac
 fi
 
 
-if [ ! -f  "${PWD}/yocto-controller/controller.cfg" ]; then
+if [ ! -f  "${YOCTO_AB_CONFIG_DIR}/yocto-controller/controller.cfg" ]; then
 echo ""
 echo "Creating yocto-controller/controller.cfg from an example 
controlle

Re: [yocto] [autobuilder][PATCH 1/4] README: update filenames and locations

[Joe MacDonald]

[Re: [yocto] [autobuilder][PATCH 1/4] README: update filenames and locations] 
On 15.02.19 (Thu 16:54) Flanagan, Elizabeth wrote:

> Pulled to master. Production this evening. Thanks!

Cool, thanks.  If you haven't already, please drop my 'templates' patch
from consideration, I figure I'll send out the completed version,
including external configuration support, for consideration soon.  It
works well for me and I don't know that the half-step is really worth
it.

FWIW, it'll still be two separate patches, if you opt to pick the first
and not the second, I'll just include both in a single thread.

-J.

> 
> On 17 February 2015 at 21:41, Joe MacDonald  wrote:
> > The main README points at conf/autobuilder.conf and conf/yoctoAB.conf,
> > both of which aren't the current places where the autobuilder looks for
> > these files anymore.
> >
> > README-NEW-AUTOBUILDER has a bit of whitespace damage, in the text and in
> > the examples, so clean that up to make it more paste-friendly.
> >
> > Signed-off-by: Joe MacDonald 
> > ---
> >  README |  6 +++---
> >  README-NEW-AUTOBUILDER | 14 +++---
> >  2 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/README b/README
> > index 94dae28..06b9cbc 100644
> > --- a/README
> > +++ b/README
> > @@ -97,13 +97,13 @@ Setting up build history requires the following steps:
> >  Files used for Yocto-Autobuilder Configuration
> >  ==
> >
> > -Name: conf/autobuilder.conf
> > +Name: config/autobuilder.conf
> >  Purpose:
> >  This file is used to set autobuilder wide parameters, like where various 
> > build
> >  artifacts are published to, DL_DIR, SSTATE_DIR or if build artifacts 
> > should be
> >  published (needed for production autobuilders, not needed for desktop 
> > builders)
> >
> > -Name: conf/yoctoAB.conf
> > +Name: buildset-config/yoctoAB.conf
> >  Purpose:
> >  This is the main yocto autobuilder config. Documentation for this and 
> > associated
> > -format is in README_CONFIG
> > +format is in README-NEW-AUTOBUILDER
> > diff --git a/README-NEW-AUTOBUILDER b/README-NEW-AUTOBUILDER
> > index 97bbe61..73be208 100644
> > --- a/README-NEW-AUTOBUILDER
> > +++ b/README-NEW-AUTOBUILDER
> > @@ -170,12 +170,12 @@ scheduler: A list of dicts. Each item defines a 
> > scheduler associated with this
> >  This defaults to '*', meaning every month.
> > dayOfWeek: The day of the week in which to start the build, 
> > with
> >  Monday = 1.  This defaults to '*', meaning every day.
> > -  hour: The hour of the day in which to start the build, with
> > +   hour: The hour of the day in which to start the build, with
> >  12:00 AM = 0.  This must be set by the user.
> > -  minute: The minute of the hour in which to start the build, 
> > with
> > +   minute: The minute of the hour in which to start the build, 
> > with
> >  0 to 59 as valid values.  This must be set by the user.
> >
> > - SingleBranchScheduler properties:
> > +   SingleBranchScheduler properties:
> > repository: the repository to attach the scheduler to; this
> >  is the repo name from the 'repos' section; the branch 
> > which
> >  the scheduler is attached to matches that in the repo
> > @@ -185,7 +185,7 @@ scheduler: A list of dicts. Each item defines a 
> > scheduler associated with this
> >  triggering build to allow for changes to settle.  
> > Defaults
> >  to 60 seconds.
> >
> > -  change-user: the user name which the remote hook will use; 
> > the
> > +   change-user: the user name which the remote hook will use; 
> > the
> >  default value is the repository name as per the 
> > 'repository'
> >  property.
> >
> > @@ -209,7 +209,7 @@ scheduler: A list of dicts. Each item defines a 
> > scheduler associated with this
> > Extra Notes on SingleBranchScheduler setup
> > --
> >
> > -  There is one SBS scheduler for each repository in the buildset, 
> > i.e.,
> > +   There is one SBS scheduler for each repository in the buildset, 
&g

[yocto] [meta-selinux][PATCH] layer: update configuration and dependencies

[Joe MacDonald]

Add in support for optional bbappends based on the presence of other
layers in the project and move the lxc recipe to a meta-virtualization
location.

Signed-off-by: Joe MacDonald 
---
 README  | 13 +
 conf/layer.conf |  9 +
 .../recipes-containers}/lxc/lxc_%.bbappend  |  0
 3 files changed, 18 insertions(+), 4 deletions(-)
 rename {recipes-containers => 
meta-virtualization/recipes-containers}/lxc/lxc_%.bbappend (100%)

diff --git a/README b/README
index 926d880..3fe8af4 100644
--- a/README
+++ b/README
@@ -34,6 +34,19 @@ the Yocto Project website:
 
 http://www.yoctoproject.org
 
+This layer also optionally depends on the following layers:
+
+URI: git://github.com/openembedded/meta-oe.git
+branch: master
+revision: HEAD
+layers: meta-oe
+meta-networking
+meta-python
+
+URI: git://git.yoctoproject.org/meta-virtualization
+branch: master
+revision: HEAD
+
 
 Maintenance
 ---
diff --git a/conf/layer.conf b/conf/layer.conf
index 723f5a8..39ae7bf 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -5,6 +5,11 @@ BBPATH .= ":${LAYERDIR}"
 BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
 ${LAYERDIR}/recipes-*/*/*.bbappend"
 
+# Let us add layer-specific bbappends which are only applied when that
+# layer is included in our configuration
+BBFILES += "${@' '.join('${LAYERDIR}/%s/recipes*/*/*.bbappend' % layer \
+   for layer in BBFILE_COLLECTIONS.split())}"
+
 BBFILE_COLLECTIONS += "selinux"
 BBFILE_PATTERN_selinux = "^${LAYERDIR}/"
 BBFILE_PRIORITY_selinux = "5"
@@ -15,8 +20,4 @@ LAYERVERSION_selinux = "1"
 
 LAYERDEPENDS_selinux = " \
 core \
-meta-python \
-networking-layer \
-openembedded-layer \
-virtualization-layer \
 "
diff --git a/recipes-containers/lxc/lxc_%.bbappend 
b/meta-virtualization/recipes-containers/lxc/lxc_%.bbappend
similarity index 100%
rename from recipes-containers/lxc/lxc_%.bbappend
rename to meta-virtualization/recipes-containers/lxc/lxc_%.bbappend
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [autobuilder][PATCH] config: support configuration templates

[Joe MacDonald]

I intended to --annotate the patch and include the [autobuilder] tag
before git-send-email ran off with it on me.  Sorry about that.

I'm sending this separately, based on the master HEAD commit, from my
documentation patches since I recognize the benefit of this may be
less obvious and maybe it's not a change upstream actually wants.  I
have one more change ready to send, supporting parallel alternate
configurations for the controller and worker, but without this change,
the next doesn't make much sense, so I thought I'd see what the
thoughts are on this change first.

On Tue, Feb 17, 2015 at 9:51 PM, Joe MacDonald  wrote:
> Move yocto-controller and yocto-worker to .template versions and update
> the setup script to move them in the expected location if they aren't
> already preset, allowing local configurations to make whatever changes
> they need in the yocto-[controller|worker] directories without issues on a
> pull and without having to resort to tools like git-diff and git-checkout
> to try alternate configurations.
>
> Signed-off-by: Joe MacDonald 
> ---
>  .gitignore |  14 ++--
>  yocto-autobuilder-setup|  37 
> +
>  .../Makefile   |   0
>  .../buildbot.tac.example   |   0
>  .../buildbot.tac.standard  |   0
>  .../controller.cfg.example |   0
>  .../public_html/bg_gradient.jpg| Bin
>  .../public_html/default.css|   0
>  .../public_html/favicon.ico| Bin
>  .../public_html/robots.txt |   0
>  .../templates/README.txt   |   0
>  .../yoctoABConfig.py   |   0
>  {yocto-worker => yocto-worker.template}/Makefile   |   0
>  .../buildbot.tac.example   |   0
>  14 files changed, 39 insertions(+), 12 deletions(-)
>  rename {yocto-controller => yocto-controller.template}/Makefile (100%)
>  rename {yocto-controller => yocto-controller.template}/buildbot.tac.example 
> (100%)
>  rename {yocto-controller => yocto-controller.template}/buildbot.tac.standard 
> (100%)
>  rename {yocto-controller => 
> yocto-controller.template}/controller.cfg.example (100%)
>  rename {yocto-controller => 
> yocto-controller.template}/public_html/bg_gradient.jpg (100%)
>  rename {yocto-controller => 
> yocto-controller.template}/public_html/default.css (100%)
>  rename {yocto-controller => 
> yocto-controller.template}/public_html/favicon.ico (100%)
>  rename {yocto-controller => 
> yocto-controller.template}/public_html/robots.txt (100%)
>  rename {yocto-controller => yocto-controller.template}/templates/README.txt 
> (100%)
>  rename {yocto-controller => yocto-controller.template}/yoctoABConfig.py 
> (100%)
>  rename {yocto-worker => yocto-worker.template}/Makefile (100%)
>  rename {yocto-worker => yocto-worker.template}/buildbot.tac.example (100%)
>
> diff --git a/.gitignore b/.gitignore
> index f1f9e4e..017636f 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -15,15 +15,5 @@
>  .cfg
>
>  TODO
> -yocto-controller/http.log
> -yocto-controller/controller.cfg
> -yocto-controller/state.sqlite
> -yocto-controller/twistd.log*
> -yocto-controller/buildbot.tac
> -yocto-worker/build-appliance/build(newcommits)
> -yocto-worker/buildbot.tac
> -yocto-worker/nightly-x86/.buildbot-sourcedata-YnVpbGQ=
> -yocto-worker/nightly/build(newcommits)
> -yocto-worker/twistd.hostname
> -yocto-worker/twistd.log*
> -yocto-worker/twistd.pid
> +yocto-controller
> +yocto-worker
> diff --git a/yocto-autobuilder-setup b/yocto-autobuilder-setup
> index 615deb4..8d447f7 100644
> --- a/yocto-autobuilder-setup
> +++ b/yocto-autobuilder-setup
> @@ -62,6 +62,25 @@ export OGIT_TRASH_CRON_TIME="0 0 * * *"
>  export OGIT_TRASH_NICE_LEVEL="19"
>  HOST_ADDR=$(hostname -I)
>
> +#
> +#
> +# Create a new controller/worker configuation based on our templates if we 
> don't
> +# already have one configured here.
> +#
> +#
> +if [ ! -d "${PWD}/yocto-controller" ]; then
> +echo ""
> +echo "Creating yocto-controller/ from yocto-controller.template/"
> +echo ""
> +/bin/cp -R yocto-controller.template yocto-controller
> +fi
> +if [ ! -d "${PWD}/yocto-worker" ]; then
> +echo ""
> +echo "Creating yocto-worker/ from yocto-worker.template/"
> +echo ""
> +/bin/cp -R

[yocto] [PATCH] config: support configuration templates

[Joe MacDonald]

Move yocto-controller and yocto-worker to .template versions and update
the setup script to move them in the expected location if they aren't
already preset, allowing local configurations to make whatever changes
they need in the yocto-[controller|worker] directories without issues on a
pull and without having to resort to tools like git-diff and git-checkout
to try alternate configurations.

Signed-off-by: Joe MacDonald 
---
 .gitignore |  14 ++--
 yocto-autobuilder-setup|  37 +
 .../Makefile   |   0
 .../buildbot.tac.example   |   0
 .../buildbot.tac.standard  |   0
 .../controller.cfg.example |   0
 .../public_html/bg_gradient.jpg| Bin
 .../public_html/default.css|   0
 .../public_html/favicon.ico| Bin
 .../public_html/robots.txt |   0
 .../templates/README.txt   |   0
 .../yoctoABConfig.py   |   0
 {yocto-worker => yocto-worker.template}/Makefile   |   0
 .../buildbot.tac.example   |   0
 14 files changed, 39 insertions(+), 12 deletions(-)
 rename {yocto-controller => yocto-controller.template}/Makefile (100%)
 rename {yocto-controller => yocto-controller.template}/buildbot.tac.example 
(100%)
 rename {yocto-controller => yocto-controller.template}/buildbot.tac.standard 
(100%)
 rename {yocto-controller => yocto-controller.template}/controller.cfg.example 
(100%)
 rename {yocto-controller => 
yocto-controller.template}/public_html/bg_gradient.jpg (100%)
 rename {yocto-controller => yocto-controller.template}/public_html/default.css 
(100%)
 rename {yocto-controller => yocto-controller.template}/public_html/favicon.ico 
(100%)
 rename {yocto-controller => yocto-controller.template}/public_html/robots.txt 
(100%)
 rename {yocto-controller => yocto-controller.template}/templates/README.txt 
(100%)
 rename {yocto-controller => yocto-controller.template}/yoctoABConfig.py (100%)
 rename {yocto-worker => yocto-worker.template}/Makefile (100%)
 rename {yocto-worker => yocto-worker.template}/buildbot.tac.example (100%)

diff --git a/.gitignore b/.gitignore
index f1f9e4e..017636f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,15 +15,5 @@
 .cfg
 
 TODO
-yocto-controller/http.log
-yocto-controller/controller.cfg
-yocto-controller/state.sqlite
-yocto-controller/twistd.log*
-yocto-controller/buildbot.tac
-yocto-worker/build-appliance/build(newcommits)
-yocto-worker/buildbot.tac
-yocto-worker/nightly-x86/.buildbot-sourcedata-YnVpbGQ=
-yocto-worker/nightly/build(newcommits)
-yocto-worker/twistd.hostname
-yocto-worker/twistd.log*
-yocto-worker/twistd.pid
+yocto-controller
+yocto-worker
diff --git a/yocto-autobuilder-setup b/yocto-autobuilder-setup
index 615deb4..8d447f7 100644
--- a/yocto-autobuilder-setup
+++ b/yocto-autobuilder-setup
@@ -62,6 +62,25 @@ export OGIT_TRASH_CRON_TIME="0 0 * * *"
 export OGIT_TRASH_NICE_LEVEL="19"
 HOST_ADDR=$(hostname -I)
 
+#
+#
+# Create a new controller/worker configuation based on our templates if we 
don't
+# already have one configured here.
+#
+#
+if [ ! -d "${PWD}/yocto-controller" ]; then
+echo ""
+echo "Creating yocto-controller/ from yocto-controller.template/"
+echo ""
+/bin/cp -R yocto-controller.template yocto-controller
+fi
+if [ ! -d "${PWD}/yocto-worker" ]; then
+echo ""
+echo "Creating yocto-worker/ from yocto-worker.template/"
+echo ""
+/bin/cp -R yocto-worker.template yocto-worker
+fi
+
 ##
 #
 # Check to see if we've got a username/password set
@@ -129,6 +148,24 @@ if [  ! -d  "./buildset-config" ]; then
 /bin/cp -R buildset-config.controller buildset-config
 fi
 
+#
+#
+# If there is already a state.sqlite file in the controller directory, it may
+# need upgrading.  Inform the user about this.  This command is run
+# automatically the first time it is run on a pristine configuration.  See
+# below.
+#
+#
+if [ -f ]; then
+echo ""
+echo "An existing yocto-controller/state.sqlite has been found."
+echo "If you have changed your configuration since the last time"
+echo "you sourced this setup script, you will most likely need to"
+echo "update it.  The command you probably want is:"
+echo ""
+echo "\tbuildbot upgrade-master ${PWD}/yocto-controller"
+echo ""
+fi
 
 if [ -n "${config_check:+x}" ]; then

[yocto] [autobuilder][PATCH 1/4] README: update filenames and locations

[Joe MacDonald]

The main README points at conf/autobuilder.conf and conf/yoctoAB.conf,
both of which aren't the current places where the autobuilder looks for
these files anymore.

README-NEW-AUTOBUILDER has a bit of whitespace damage, in the text and in
the examples, so clean that up to make it more paste-friendly.

Signed-off-by: Joe MacDonald 
---
 README |  6 +++---
 README-NEW-AUTOBUILDER | 14 +++---
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/README b/README
index 94dae28..06b9cbc 100644
--- a/README
+++ b/README
@@ -97,13 +97,13 @@ Setting up build history requires the following steps:
 Files used for Yocto-Autobuilder Configuration
 ==
 
-Name: conf/autobuilder.conf
+Name: config/autobuilder.conf
 Purpose:
 This file is used to set autobuilder wide parameters, like where various build
 artifacts are published to, DL_DIR, SSTATE_DIR or if build artifacts should be
 published (needed for production autobuilders, not needed for desktop builders)
 
-Name: conf/yoctoAB.conf
+Name: buildset-config/yoctoAB.conf
 Purpose:
 This is the main yocto autobuilder config. Documentation for this and 
associated
-format is in README_CONFIG
+format is in README-NEW-AUTOBUILDER
diff --git a/README-NEW-AUTOBUILDER b/README-NEW-AUTOBUILDER
index 97bbe61..73be208 100644
--- a/README-NEW-AUTOBUILDER
+++ b/README-NEW-AUTOBUILDER
@@ -170,12 +170,12 @@ scheduler: A list of dicts. Each item defines a scheduler 
associated with this
 This defaults to '*', meaning every month.
dayOfWeek: The day of the week in which to start the build, with
 Monday = 1.  This defaults to '*', meaning every day.
-  hour: The hour of the day in which to start the build, with 
+   hour: The hour of the day in which to start the build, with
 12:00 AM = 0.  This must be set by the user.
-  minute: The minute of the hour in which to start the build, with
+   minute: The minute of the hour in which to start the build, with
 0 to 59 as valid values.  This must be set by the user.
 
- SingleBranchScheduler properties:
+   SingleBranchScheduler properties:
repository: the repository to attach the scheduler to; this
 is the repo name from the 'repos' section; the branch which
 the scheduler is attached to matches that in the repo
@@ -185,7 +185,7 @@ scheduler: A list of dicts. Each item defines a scheduler 
associated with this
 triggering build to allow for changes to settle.  Defaults
 to 60 seconds.
 
-  change-user: the user name which the remote hook will use; the
+   change-user: the user name which the remote hook will use; the
 default value is the repository name as per the 
'repository'
 property.
 
@@ -209,7 +209,7 @@ scheduler: A list of dicts. Each item defines a scheduler 
associated with this
Extra Notes on SingleBranchScheduler setup
--
 
-  There is one SBS scheduler for each repository in the buildset, i.e.,
+   There is one SBS scheduler for each repository in the buildset, 
i.e.,
if your buildset contains more repositories, and you want build
triggered by changes to any of them, you need to define a scheduler
for each. This also means that you can mix and match, e.g., only
@@ -272,8 +272,8 @@ steps: [{'SetDest':{}},
 {'PublishArtifacts': {'artifacts': ['qemux86', 'atom-pc']}}]
 scheduler: [{'dev-branch-scheduler' :
 {'type':'SingleBranchScheduler',
-'repository':'poky',
-'stable-timer':30,
+ 'repository':'poky',
+ 'stable-timer':30,
  'change-password':'secret_change_password'}}]
 
 Adding Buildsteps
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [autobuilder][PATCH 4/4] janitor: clean up janitor logging

[Joe MacDonald]

If OPTIMIZED_GIT_CLONE was set, the worker janitor was start up and
depending on the system, produce an error of the form:

/bin/sh: line 1: 11093 Killed  python bin/buildworker-janitor 
[path-to--autobuilder]/config/autobuilder.conf >> yocto-worker/janitor.log 2>&1

By removing the shell-redirect from the Popen() call and instead sending
all logs directly to a regular log file, the error goes to the log where
it belongs.  Since this happens regularly when the host is both a control
and a build node, this change also makes it clearer to the user that
something bad has not necessarily happened the first time they try to
start up the autobuilder.

At the same time, since the logs tend to not have much in them by way of
context, adding a timestamp to each new start of the janitor makes it much
easier when looking over the old logs to see if errors are current or long
in the past.

Signed-off-by: Joe MacDonald 
---
 yocto-start-autobuilder | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/yocto-start-autobuilder b/yocto-start-autobuilder
index 7078163..ee597df 100755
--- a/yocto-start-autobuilder
+++ b/yocto-start-autobuilder
@@ -20,7 +20,7 @@
 # along with this program; if not, write to the Free Software
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 
-import os, sys, optparse, subprocess
+import os, sys, optparse, subprocess, datetime
 from socket import gethostname
 import ConfigParser
 
@@ -79,10 +79,15 @@ if os.path.isfile(os.path.join(AB_BASE, ".setupdone")):
 os.chdir(AB_BASE)
 if os.environ["OPTIMIZED_GIT_CLONE"] == "True":
 os.chdir(AB_BASE)
-subprocess.Popen("python bin/buildworker-janitor " + 
os.path.join(AB_BASE, "config/autobuilder.conf") + ">> yocto-worker/janitor.log 
2>&1", 
+janitor_log = open('yocto-worker/janitor.log', 'a')
+janitor_log.write('[ janitor started: %s ]' % 
datetime.datetime.now())
+janitor_log.write('\n')
+subprocess.Popen("python bin/buildworker-janitor " + 
os.path.join(AB_BASE, "config/autobuilder.conf"), 
shell=True, stdin=None, 
-   stdout=None, stderr=None, 
+   stdout=janitor_log,
+   stderr=janitor_log, 
close_fds=True)
+janitor_log.close()
 else:
 print "You have not sourced ./yocto-autobuilder-setup. Please do so first!"
 print ""
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [autobuilder][PATCH 3/4] gitignore: add worker-init

[Joe MacDonald]

yocto-autobuilder-setup modifies bin/worker-init on every new deployment,
so we don't want to consider worker-init for tracking by default.

Signed-off-by: Joe MacDonald 
---
 .gitignore | 5 +
 1 file changed, 5 insertions(+)

diff --git a/.gitignore b/.gitignore
index cb595bb..a4b31c6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -33,3 +33,8 @@ yocto-worker/nightly/build(newcommits)
 yocto-worker/twistd.hostname
 yocto-worker/twistd.log*
 yocto-worker/twistd.pid
+
+# This gets updated on every yocto-setup-autobuilder so should be ignored #
+# for nearly everyone.#
+###
+bin/worker-init
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [autobuilder][PATCH 2/4] gitignore: add janitor log and additional config files

[Joe MacDonald]

The janitor log for workers was missing from gitignore, so add it.

Every deployment is expected to make their own changes to buildset-config,
so add the whole directory to the ignore list.

Similarly, every deployment is likely to make their own changes to
config/autobuilder.conf, so ignore changes to it as well.

Signed-off-by: Joe MacDonald 
---
 .gitignore | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/.gitignore b/.gitignore
index f1f9e4e..cb595bb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,6 +4,11 @@
 *.so
 *.pyc
 
+# Configuration hunks, changed by anyone using AB #
+###
+buildset-config
+config/autobuilder.conf
+
 # Everything else #
 ###
 *.log.*
@@ -22,6 +27,7 @@ yocto-controller/twistd.log*
 yocto-controller/buildbot.tac
 yocto-worker/build-appliance/build(newcommits)
 yocto-worker/buildbot.tac
+yocto-worker/janitor.log
 yocto-worker/nightly-x86/.buildbot-sourcedata-YnVpbGQ=
 yocto-worker/nightly/build(newcommits)
 yocto-worker/twistd.hostname
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] "New" Dependencies (was: Re: [meta-selinux][PATCH] Add explicit dependency on layers with recipes we bbappend.)

[Joe MacDonald]

I thought I'd better follow this up with a semi-separate thread for
anyone who is using meta-selinux and isn't really interested in the
direct follow-ups when I just indicate a patch has been merged.

This went into master and it captures, I think, the implicit
dependencies in the layer right now.  It actually casts a wider net than
is required if you're building core-image-selinux, but it does describe
what's currently included in the layer in terms of appends, so it's the
right thing to do.

If you've been working with a smaller set of selinux layers before,
you'll probably see an error like this:

ERROR: Layer 'selinux' depends on layer 'meta-python', but this layer is not 
enabled in your configuration
ERROR: Layer 'selinux' depends on layer 'networking-layer', but this layer is 
not enabled in your configuration
ERROR: Layer 'selinux' depends on layer 'openembedded-layer', but this layer is 
not enabled in your configuration
ERROR: Layer 'selinux' depends on layer 'virtualization-layer', but this layer 
is not enabled in your configuration

If you don't want to bring in all of these additional layers, my advice
for the short term is to stick with either the 1.7 branch or if you know
you need to work on master, stick with commit 0d270cbd.

-J.

[Re: [meta-selinux][PATCH] Add explicit dependency on layers with recipes we 
bbappend.] On 15.02.12 (Thu 08:16) Joe MacDonald wrote:

> [[meta-selinux][PATCH] Add explicit dependency on layers with recipes we 
> bbappend.] On 15.02.12 (Thu 04:39) Philip Tricca wrote:
> 
> > This is a stop-gap to get meaningful error messages to folks till we get
> > per-layer bbappends implemented.
> > 
> > Signed-off-by: Philip Tricca 
> 
> Merged.  Thanks Phil.
> 
> -J.
> 
> > ---
> >  conf/layer.conf |8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/conf/layer.conf b/conf/layer.conf
> > index 7af76a1..723f5a8 100644
> > --- a/conf/layer.conf
> > +++ b/conf/layer.conf
> > @@ -13,4 +13,10 @@ BBFILE_PRIORITY_selinux = "5"
> >  # cause compatibility issues with other layers
> >  LAYERVERSION_selinux = "1"
> >  
> > -LAYERDEPENDS_selinux = "core"
> > +LAYERDEPENDS_selinux = " \
> > +core \
> > +meta-python \
> > +networking-layer \
> > +openembedded-layer \
> > +virtualization-layer \
> > +"
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] Add explicit dependency on layers with recipes we bbappend.

[Joe MacDonald]

[[meta-selinux][PATCH] Add explicit dependency on layers with recipes we 
bbappend.] On 15.02.12 (Thu 04:39) Philip Tricca wrote:

> This is a stop-gap to get meaningful error messages to folks till we get
> per-layer bbappends implemented.
> 
> Signed-off-by: Philip Tricca 

Merged.  Thanks Phil.

-J.

> ---
>  conf/layer.conf |8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/conf/layer.conf b/conf/layer.conf
> index 7af76a1..723f5a8 100644
> --- a/conf/layer.conf
> +++ b/conf/layer.conf
> @@ -13,4 +13,10 @@ BBFILE_PRIORITY_selinux = "5"
>  # cause compatibility issues with other layers
>  LAYERVERSION_selinux = "1"
>  
> -LAYERDEPENDS_selinux = "core"
> +LAYERDEPENDS_selinux = " \
> +core \
> +meta-python \
> +networking-layer \
> +openembedded-layer \
> +virtualization-layer \
> +"
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [oe] meta-selinux

[Joe MacDonald]

e images for dom0, a user interface
> > domain, a network driver domain, and various other service domains for
> > isolating tasks in the platform. In addition to that we're using
> > openembedded for building on various embedded research platforms. I'm
> > assuming yocto is using SELinux to some extent since they are
> > maintaining the repository for it and there are quite a few developers
> > using SELiunx on embedded products in Japan.
> 
> I guess I've been wondering the same thing. For OpenXT we had
> implemented our own SELinux support on top of OE (we weren't OSS at the
> time). Now that we are OSS we've re-based on meta-selinux but I don't
> know of anyone else using this layer or at least discussing it publicly.

There's certainly a few other groups / companies, but I'm certain
they're all using the 1.7 branch for now, not master, and manually
updating to the latest refpolicy release (which came out days after we
branched for 1.7) in their own tree.  I'm preparing an update to the
newest refpolicy now, but we're also not far away from the next one, so
I'm almost tempted to wait it out at this point and jump right to the
201503* refpolicy.  I'd be interested to hear opinions on that from
anyone using meta-selinux and wanting to use the master branch.

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [oe] meta-selinux

[Joe MacDonald]

[Re: [oe] meta-selinux] On 15.02.11 (Wed 16:29) Paul Eggleton wrote:

> (Adding yocto@yoctoproject.org to CC since that is where meta-selinux patches 
> tend to go at least)
> 
> On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
> > I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> > by the yocto project. I'm trying to use it with a base openembedded core
> > and its not in sync with oe-core because its based on pokey. 
> 
> To be clear, poky and OE-Core are in lock-step. No patch to core recipes goes 
> into Poky directly, they are applied to OE-Core and then they flow into Poky 
> immediately thereafter (Richard, who does the merging of patches into 
> OE-Core, 
> does the sync to Poky immediately afterwards.)
> 
> What's more likely happening I suspect is that you are on a newer 
> branch/revision of OE-Core/Poky than the meta-selinux maintainers have 
> tested. 
> I can't speak to the maintenance schedule for meta-selinux but maybe others 
> with knowledge there can chime in.

Our master tends to lag behind oe-core's master for a few reasons, but
none of them are really insurmountable.  Certainly the intent is that
meta-selinux/master will build successfully with oe-core/master at any
given time.

> > This made me think of two questions. 1) Why is this not in OE core since so
> > many packages in core can potentially have SELinux support enabled and 2) if
> > its not supposed to be in core where should turning on SELinux support
> > in a recipe go? For example coreutils can have SELinux support enabled.
> > Currently this is in meta-selinux as a bbappend to the coreutils
> > package. This works out because its always going to be there. However
> > there is also a bbappend for an LXC recipe. LXC isn't in core which
> > means it has a dependency on a layer not in core.
> > 
> > Ideally I would put the recipes needed for SELinux support in core and
> > have a distro feature which is checked in the recipes in core for
> > whether or not to add --with-selinux to the build flags. Then LXC could
> > check a core distro feature and enable SELinux if it wants to.
> 
> We have to draw the line somewhere for what to include in OE-Core, and at the 
> moment I guess we have considered SELinux to be outside its scope. Obviously 
> these things get re-evaluated from time to time, and SELinux is a little bit 
> painful for this because of how many recipes it has to touch. Ultimately it 
> depends on how many people in the embedded space want to enable and use 
> SELinux.
> 
> Thoughts from others?

I've been doing SELinux stuff for rather a long time and it's generally
been my experience that there's a set of developers / vendors that
*really* want it and know what they're doing, there's another set that
*really* want nothing to do with it and a group that say they want
SELinux support but then immediately start needing to turn stuff off
because it causes their system to behave too differently.

Taken as a simple maintenance thing, I think it's easier to have SELinux
be part of OE-Core.  Given, though, it's really not possible to divorce
much of SELinux functionality from python on the target, so then I don't
know if it really makes sense for something like that to be part of
oe-core, proper.  I would think no.

> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [oe] meta-selinux

[Joe MacDonald]

[Re: [oe] meta-selinux] On 15.02.11 (Wed 11:55) dpquigl wrote:

> On Wed, 2015-02-11 at 16:29 +, Paul Eggleton wrote:
> > (Adding yocto@yoctoproject.org to CC since that is where meta-selinux 
> > patches 
> > tend to go at least)
> > 
> > On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
> > > I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> > > by the yocto project. I'm trying to use it with a base openembedded core
> > > and its not in sync with oe-core because its based on pokey. 
> > 
> > To be clear, poky and OE-Core are in lock-step. No patch to core recipes 
> > goes 
> > into Poky directly, they are applied to OE-Core and then they flow into 
> > Poky 
> > immediately thereafter (Richard, who does the merging of patches into 
> > OE-Core, 
> > does the sync to Poky immediately afterwards.)
> > 
> > What's more likely happening I suspect is that you are on a newer 
> > branch/revision of OE-Core/Poky than the meta-selinux maintainers have 
> > tested. 
> > I can't speak to the maintenance schedule for meta-selinux but maybe others 
> > with knowledge there can chime in.
> 
> 
> I think this makes the most sense. 3 of the problems were bbappend files
> trying to append the wrong version of a recipe (although with these
> changes I should move them over to a wildcard) and the last one was with
> LXC. After that I encountered a typo in one of the recipes where it
> wasn't able to pull the sources down. 

I merged a set of patches just in the last couple of days that addresses
a SRC_URI issue and wildcards for bbappends that I hope resolves all of
the current crop of these.  If you update your tree now you will likely
see those go away.  If not, please let me know.

Alternatively, I'm not aware of any issues in 1.7 of that sort (though
now that I think about it, I need to check the SRC_URI one, I bet that's
there), so using the latest released Yocto with a like-named branch in
meta-selinux should always be safe.

-J.

> > > This made me think of two questions. 1) Why is this not in OE core since 
> > > so
> > > many packages in core can potentially have SELinux support enabled and 2) 
> > > if
> > > its not supposed to be in core where should turning on SELinux support
> > > in a recipe go? For example coreutils can have SELinux support enabled.
> > > Currently this is in meta-selinux as a bbappend to the coreutils
> > > package. This works out because its always going to be there. However
> > > there is also a bbappend for an LXC recipe. LXC isn't in core which
> > > means it has a dependency on a layer not in core.
> > > 
> > > Ideally I would put the recipes needed for SELinux support in core and
> > > have a distro feature which is checked in the recipes in core for
> > > whether or not to add --with-selinux to the build flags. Then LXC could
> > > check a core distro feature and enable SELinux if it wants to.
> > 
> > We have to draw the line somewhere for what to include in OE-Core, and at 
> > the 
> > moment I guess we have considered SELinux to be outside its scope. 
> > Obviously 
> > these things get re-evaluated from time to time, and SELinux is a little 
> > bit 
> > painful for this because of how many recipes it has to touch. Ultimately it 
> > depends on how many people in the embedded space want to enable and use 
> > SELinux.
> > 
> > Thoughts from others?
> > 
> 
> In OpenXT we're using OE to generate images for dom0, a user interface
> domain, a network driver domain, and various other service domains for
> isolating tasks in the platform. In addition to that we're using
> openembedded for building on various embedded research platforms. I'm
> assuming yocto is using SELinux to some extent since they are
> maintaining the repository for it and there are quite a few developers
> using SELiunx on embedded products in Japan.
> 
> 
> Dave
> 
> 
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][ 0/3] v2 More recipe updates.

[Joe MacDonald]

[[meta-selinux][ 0/3] v2 More recipe updates.] On 15.01.15 (Thu 02:59) Philip 
Tricca wrote:

> Greetings,
> 
> Three more recipe udpates to get meta-selinux building with oe-core master
> again. These are mostly mundane though the move from findutils from 4.4.x
> to 4.5.x removes the need for patches that have since gone upstream. This
> v2 patch set takes into account comments from Mark w/r to removing PRs due
> to the uprev.
> 
> Best,
> Philip

Thanks for these, Philip, I'd been starting to do the same work myself
but got distracted while auditing the findutils patches.  Merged.

-J.

> 
> Philip Tricca (3):
>   findutils: Upgrade recipe to 4.5 and use wildcard for pico version.
>   logrotate: Use wildcard for version number.
>   tar: Use wildcard for version number in bbappend.
> 
>  .../findutils-with-selinux-gnulib.patch|   55 --
>  .../findutils-4.4.2/findutils-with-selinux.patch   |  528 
> 
>  .../findutils/findutils_4.4.2.bbappend |   14 -
>  .../findutils/findutils_4.5.%.bbappend |2 +
>  recipes-extended/logrotate/logrotate_%.bbappend|5 +
>  .../logrotate/logrotate_3.8.7.bbappend |7 -
>  recipes-extended/tar/tar_%.bbappend|   11 +
>  recipes-extended/tar/tar_1.27.1.bbappend   |   13 -
>  8 files changed, 18 insertions(+), 617 deletions(-)
>  delete mode 100644 
> recipes-extended/findutils/findutils-4.4.2/findutils-with-selinux-gnulib.patch
>  delete mode 100644 
> recipes-extended/findutils/findutils-4.4.2/findutils-with-selinux.patch
>  delete mode 100644 recipes-extended/findutils/findutils_4.4.2.bbappend
>  create mode 100644 recipes-extended/findutils/findutils_4.5.%.bbappend
>  create mode 100644 recipes-extended/logrotate/logrotate_%.bbappend
>  delete mode 100644 recipes-extended/logrotate/logrotate_3.8.7.bbappend
>  create mode 100644 recipes-extended/tar/tar_%.bbappend
>  delete mode 100644 recipes-extended/tar/tar_1.27.1.bbappend
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-selinux] lxc: inherit enable-selinux

[Joe MacDonald]

[[yocto] [PATCH][meta-selinux] lxc: inherit enable-selinux] On 15.01.21 (Wed 
17:49) rongqing...@windriver.com wrote:

> From: Roy Li 
> 
> inherit enable-selinux to kill the warning that lxc rdepends on libselinux,
> but it isn't a build dependency
> 
> Signed-off-by: Roy Li 

Merged, thanks Roy.

-J.

> ---
>  recipes-containers/lxc/lxc_%.bbappend | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 100644 recipes-containers/lxc/lxc_%.bbappend
> 
> diff --git a/recipes-containers/lxc/lxc_%.bbappend 
> b/recipes-containers/lxc/lxc_%.bbappend
> new file mode 100644
> index 000..8c11cac
> --- /dev/null
> +++ b/recipes-containers/lxc/lxc_%.bbappend
> @@ -0,0 +1 @@
> +inherit enable-selinux
> -- 
> 2.1.0
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] audit-systemd: allow manual stop as sysvinit

[Joe MacDonald]

Merged, thanks, Jackie.

-J.

[[yocto] [meta-selinux][PATCH] audit-systemd: allow manual stop as sysvinit] On 
15.01.14 (Wed 13:30) jackie.hu...@windriver.com wrote:

> From: Jackie Huang 
> 
> The audit service should be manually stopped with systemd.
> 
> Signed-off-by: Jackie Huang 
> ---
>  recipes-security/audit/audit/auditd.service | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/recipes-security/audit/audit/auditd.service 
> b/recipes-security/audit/audit/auditd.service
> index adf4d3b..ebc0798 100644
> --- a/recipes-security/audit/audit/auditd.service
> +++ b/recipes-security/audit/audit/auditd.service
> @@ -5,7 +5,6 @@ After=local-fs.target
>  Conflicts=shutdown.target
>  Before=sysinit.target shutdown.target
>  After=systemd-tmpfiles-setup.service
> -RefuseManualStop=yes
>  
>  [Service]
>  ExecStart=/sbin/auditd -n
> -- 
> 1.9.1
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH 1/3] V2 refpolicy:20140311 update for systemd

[Joe MacDonald]

Hi Shrikant,

All three of these have been merged.  Thanks.  And my apologies to
everyone on the delay for these patches.

-J.

[Re: [yocto] [meta-selinux][PATCH 1/3] V2 refpolicy:20140311 update for 
systemd] On 15.01.05 (Mon 17:12) Shrikant Bobade wrote:

> Hello,
> 
> Please provide review comments or feedback if any, It will be a great help. 
> @Ping.
> 
> Thanks
> Shrikant
> 
> On Wed, Nov 19, 2014 at 1:43 PM, Shrikant Bobade 
> wrote:
> 
> From: Shrikant Bobade 
> 
> Systemd init type and related allow rules
> updated for refpolicy.
> 
> Signed-off-by: Shrikant Bobade 
> ---
>  .../refpolicy-update-for_systemd.patch |   46
> 
>  .../refpolicy/refpolicy_2.20140311.inc |1 +
>  2 files changed, 47 insertions(+)
>  create mode 100644 recipes-security/refpolicy/refpolicy-2.20140311/
> refpolicy-update-for_systemd.patch
> 
> diff --git a/recipes-security/refpolicy/refpolicy-2.20140311/
> refpolicy-update-for_systemd.patch b/recipes-security/refpolicy/
> refpolicy-2.20140311/refpolicy-update-for_systemd.patch
> new file mode 100644
> index 000..80b420c
> --- /dev/null
> +++ b/recipes-security/refpolicy/refpolicy-2.20140311/
> refpolicy-update-for_systemd.patch
> @@ -0,0 +1,46 @@
> +refpolicy: update for systemd
> +
> +It provides the systemd support for refpolicy
> +and related allow rules.
> +The restorecon provides systemd init labeled
> +as init_exec_t.
> +
> +Upstream-Status: Pending
> +
> +
> +Signed-off-by: Shrikant Bobade 
> +
> +--- a/policy/modules/contrib/shutdown.fc
>  b/policy/modules/contrib/shutdown.fc
> +@@ -5,6 +5,9 @@
> + /sbin/shutdown--  gen_context
> (system_u:object_r:shutdown_exec_t,s0)
> + /sbin/shutdown\.sysvinit  --  gen_context
> (system_u:object_r:shutdown_exec_t,s0)
> +
> ++# systemd support
> ++/bin/systemctl--  gen_context
> (system_u:object_r:shutdown_exec_t,s0)
> ++
> + /usr/lib/upstart/shutdown --  gen_context
> (system_u:object_r:shutdown_exec_t,s0)
> +
> + /usr/sbin/shutdown--  gen_context
> (system_u:object_r:shutdown_exec_t,s0)
> +--- a/policy/modules/system/init.fc
>  b/policy/modules/system/init.fc
> +@@ -31,6 +31,8 @@
> + #
> + /sbin/init(ng)?   --  gen_context
> (system_u:object_r:init_exec_t,s0)
> + /sbin/init\.sysvinit  --  gen_context
> (system_u:object_r:init_exec_t,s0)
> ++# systemd support
> ++/lib/systemd/systemd  --  gen_context
> (system_u:object_r:init_exec_t,s0)
> + # because nowadays, /sbin/init is often a symlink to /sbin/upstart
> + /sbin/upstart --  gen_context
> (system_u:object_r:init_exec_t,s0)
> +
> +--- a/policy/modules/system/init.te
>  b/policy/modules/system/init.te
> +@@ -913,3 +913,8 @@
> + optional_policy(`
> +   zebra_read_config(initrc_t)
> + ')
> ++
> ++# systemd related allow rules
> ++allow kernel_t init_t:process dyntransition;
> ++allow devpts_t device_t:filesystem associate;
> ++allow init_t self:capability2 block_suspend;
> diff --git a/recipes-security/refpolicy/refpolicy_2.20140311.inc b/
> recipes-security/refpolicy/refpolicy_2.20140311.inc
> index 8894583..557b4ab 100644
> --- a/recipes-security/refpolicy/refpolicy_2.20140311.inc
> +++ b/recipes-security/refpolicy/refpolicy_2.20140311.inc
> @@ -29,6 +29,7 @@ SRC_URI += "file://poky-fc-subs_dist.patch \
>  file://poky-fc-rpm.patch \
>  file://poky-fc-ftpwho-dir.patch \
>  file://poky-fc-fix-real-path_su.patch \
> +file://refpolicy-update-for_systemd.patch \
> "
> 
>  # Specific policy for Poky
> --
> 1.7.9.5
> 
> 
> 

-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] lsof: use wildcard for version number in bbappend

[Joe MacDonald]

Merged, thanks Jackie.
-J.

[[yocto] [meta-selinux][PATCH] lsof: use wildcard for version number in 
bbappend] On 15.01.05 (Mon 15:25) jackie.hu...@windriver.com wrote:

> From: Jackie Huang 
> 
> The recipe in oe-core is already updated:
> b463d70 lsof: Upgrade to 4.88
> 
> Signed-off-by: Jackie Huang 
> ---
>  recipes-extended/lsof/{lsof_4.87.bbappend => lsof_%.bbappend} | 0
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  rename recipes-extended/lsof/{lsof_4.87.bbappend => lsof_%.bbappend} (100%)
> 
> diff --git a/recipes-extended/lsof/lsof_4.87.bbappend 
> b/recipes-extended/lsof/lsof_%.bbappend
> similarity index 100%
> rename from recipes-extended/lsof/lsof_4.87.bbappend
> rename to recipes-extended/lsof/lsof_%.bbappend
> -- 
> 1.9.1
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-selinux] parted: Use wildcard for version number in bbappend.

[Joe MacDonald]

Merged this too.

-J.

[[PATCH][meta-selinux] parted: Use wildcard for version number in bbappend.] On 
14.12.19 (Fri 23:46) fl...@twobit.us wrote:

> From: Philip Tricca 
> 
> Signed-off-by: Philip Tricca 
> ---
>  recipes-extended/parted/parted_%.bbappend   |3 +++
>  recipes-extended/parted/parted_3.1.bbappend |3 ---
>  2 files changed, 3 insertions(+), 3 deletions(-)
>  create mode 100644 recipes-extended/parted/parted_%.bbappend
>  delete mode 100644 recipes-extended/parted/parted_3.1.bbappend
> 
> diff --git a/recipes-extended/parted/parted_%.bbappend 
> b/recipes-extended/parted/parted_%.bbappend
> new file mode 100644
> index 000..366fdf5
> --- /dev/null
> +++ b/recipes-extended/parted/parted_%.bbappend
> @@ -0,0 +1,3 @@
> +PR .= ".2"
> +
> +inherit enable-selinux
> diff --git a/recipes-extended/parted/parted_3.1.bbappend 
> b/recipes-extended/parted/parted_3.1.bbappend
> deleted file mode 100644
> index 366fdf5..000
> --- a/recipes-extended/parted/parted_3.1.bbappend
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -PR .= ".2"
> -
> -inherit enable-selinux
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-selinux] cronie: Use wildcard for version number in bbappend.

[Joe MacDonald]

Merged, thanks Philip.

-J.

[[PATCH][meta-selinux] cronie: Use wildcard for version number in bbappend.] On 
14.12.19 (Fri 23:47) fl...@twobit.us wrote:

> From: Philip Tricca 
> 
> Signed-off-by: Philip Tricca 
> ---
>  recipes-extended/cronie/cronie_%.bbappend  |3 +++
>  recipes-extended/cronie/cronie_1.4.11.bbappend |3 ---
>  2 files changed, 3 insertions(+), 3 deletions(-)
>  create mode 100644 recipes-extended/cronie/cronie_%.bbappend
>  delete mode 100644 recipes-extended/cronie/cronie_1.4.11.bbappend
> 
> diff --git a/recipes-extended/cronie/cronie_%.bbappend 
> b/recipes-extended/cronie/cronie_%.bbappend
> new file mode 100644
> index 000..a398bec
> --- /dev/null
> +++ b/recipes-extended/cronie/cronie_%.bbappend
> @@ -0,0 +1,3 @@
> +PR .= ".2"
> +
> +inherit with-selinux with-audit
> diff --git a/recipes-extended/cronie/cronie_1.4.11.bbappend 
> b/recipes-extended/cronie/cronie_1.4.11.bbappend
> deleted file mode 100644
> index a398bec..000
> --- a/recipes-extended/cronie/cronie_1.4.11.bbappend
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -PR .= ".2"
> -
> -inherit with-selinux with-audit
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-selinux] systemd: fix dependencies for audit, selinux

[Joe MacDonald]

Merged, thanks.

-J.

[[yocto] [PATCH][meta-selinux] systemd: fix dependencies for audit, selinux] On 
14.12.03 (Wed 03:58) wenzong@windriver.com wrote:

> From: Wenzong Fan 
> 
> Signed-off-by: Wenzong Fan 
> ---
>  recipes-core/systemd/systemd_%.bbappend |2 ++
>  1 file changed, 2 insertions(+)
>  create mode 100644 recipes-core/systemd/systemd_%.bbappend
> 
> diff --git a/recipes-core/systemd/systemd_%.bbappend 
> b/recipes-core/systemd/systemd_%.bbappend
> new file mode 100644
> index 000..8d9029b
> --- /dev/null
> +++ b/recipes-core/systemd/systemd_%.bbappend
> @@ -0,0 +1,2 @@
> +inherit enable-audit
> +inherit enable-selinux
> -- 
> 1.7.9.5
> 
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto