Re: [yocto] Custom defconfig is not used

2013-10-30 Thread Jukka Rissanen 

Hi Diego,

On 16.10.2013 00:07, Diego Sueiro wrote:

Folks,

I created the following bbapend recipe for linux-mainline_3.8.bb
 (from meta-beagleboard on dylan branch)
for beaglebone.
meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += " file://0019-mine.patch \
  file://defconfig \
  "

But the defconfig and .config files on ${S} and ${WORKDIR} used are from
meta-beagleboad, not from my bbappend.


I did this like this in 
http://git.yoctoproject.org/cgit/cgit.cgi/meta-eca/tree/meta-eca-bsp/recipes-kernel/linux/linux-mainline_3.8.bbappend



FILESEXTRAPATHS_append := ":${THISDIR}/${PN}"

# netfilter stuff is missing from beaglebone kernel
SRC_URI_append_beaglebone += "file://netfilter.cfg"

do_configure_append_beaglebone () {
for i in ${S}/../*.cfg; do
echo "Adding ${i} to ${S}/.config"
cat ${i} >> ${S}/.config
done

yes '' | oe_runmake oldconfig
}


Seems to work just fine for me.


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

[yocto] [Resend: PATCH] ncurses-terminfo: Remove bashism from basic terminfo installation

2013-10-30 Thread Seth Bollinger 
The vtX terminfo files aren't being copied on systems where bash isn't
the default shell (debian, etc.).  I removed the bash specific syntax
so the files are properly copied on these systems.

Signed-off-by: Seth Bollinger 
---
 meta/recipes-core/ncurses/ncurses.inc |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/ncurses/ncurses.inc 
b/meta/recipes-core/ncurses/ncurses.inc
index 671daf8..01cdf13 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -174,7 +174,7 @@ shell_do_install() {
 
 # include some basic terminfo files
 # stolen ;) from gentoo and modified a bit
-for x in ansi console dumb linux rxvt screen sun 
vt{52,100,102,200,220} xterm-color xterm-xfree86 xterm-256color
+for x in ansi console dumb linux rxvt screen sun vt52 vt100 vt102 
vt200 vt220 xterm-color xterm-xfree86 xterm-256color
 do
 local termfile="$(find "${D}${datadir}/terminfo/" -name "${x}" 
2>/dev/null)"
 local basedir="$(basename $(dirname "${termfile}"))"
-- 
1.7.10.4

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

Re: [yocto] Custom defconfig is not used

2013-10-30 Thread Bruce Ashfield 
On Wed, Oct 30, 2013 at 3:57 AM, Jukka Rissanen
 wrote:
> Hi Diego,
>
>
> On 16.10.2013 00:07, Diego Sueiro wrote:
>>
>> Folks,
>>
>> I created the following bbapend recipe for linux-mainline_3.8.bb
>>  (from meta-beagleboard on dylan branch)
>>
>> for beaglebone.
>> meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>> SRC_URI += " file://0019-mine.patch \
>>   file://defconfig \
>>   "
>>
>> But the defconfig and .config files on ${S} and ${WORKDIR} used are from
>> meta-beagleboad, not from my bbappend.
>
>
> I did this like this in
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-eca/tree/meta-eca-bsp/recipes-kernel/linux/linux-mainline_3.8.bbappend
>
>
> FILESEXTRAPATHS_append := ":${THISDIR}/${PN}"
>
> # netfilter stuff is missing from beaglebone kernel
> SRC_URI_append_beaglebone += "file://netfilter.cfg"
>
> do_configure_append_beaglebone () {
> for i in ${S}/../*.cfg; do
> echo "Adding ${i} to ${S}/.config"
> cat ${i} >> ${S}/.config
> done
>
> yes '' | oe_runmake oldconfig
> }
>
>
> Seems to work just fine for me.
>

But that's *really* not the point.

Having configuration fragments applied and managed is more than a brute force
concatenation of the contents, letting lkc do what it wants to them,
without reporting
and control is what

There's something in place, that already does this and more, which has
the ability
to scale to more complex cases.

What I'm trying to understand is what exactly is different in Diego's
setup, since
the exact cases reported here work fine for me, Andrea and any number of other
people. Something strange is going on.

We need to be patient and work through this, so if there's a bug in the already
available infrastructure, we can flush it out :)

Bruce

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



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom defconfig is not used

2013-10-30 Thread Bruce Ashfield 

On 13-10-29 11:31 AM, Diego Sueiro wrote:

Bruce,

I've created new build setup with this configuration:

BB_VERSION= "1.18.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.10"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "beaglebone"
DISTRO= "poky"
DISTRO_VERSION= "1.4.2"
TUNE_FEATURES = "armv7a vfp neon"
TARGET_FPU= "vfp-neon"
meta
meta-yocto
meta-yocto-bsp= "dylan:4e399f08d596197859214fdb3b06403b87bf8789"
meta-oe   = "dylan:a108b2203a997634f87ac687e81712badaf3c546"
common-bsp= "dylan:7fdf9c670a10c5031a2dc15c45e453de8c21"
meta-mine = "dylan:4e399f08d596197859214fdb3b06403b87bf8789"

common-bsp comes from meta-beagleboard.
meta-oe needed to be added because of machine_kernel_pr.bbclass.


FYI: I've created this exactly environment on my builder. I'll follow up
shortly with the results of the two scenarios.

Honestly, I hope it breaks .. that'll make it much easier to debug :)

Bruce



bblayers.conf:

LCONF_VERSION = "6"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
  ${TOPDIR}/meta \
  ${TOPDIR}/meta-yocto \
  ${TOPDIR}/meta-yocto-bsp \
${TOPDIR}/meta-openembedded/meta-oe \
  ${TOPDIR}/meta-beagleboard/common-bsp \
  ${TOPDIR}/meta-mine \
  "

meta-mine:

conf/layer.conf:

BBPATH .= ":${LAYERDIR}"
BBFILES += "${LAYERDIR}/recipes*/*/*.bb
${LAYERDIR}/recipes*/*/*.bbappend"
BBFILE_COLLECTIONS += "my-layer"
BBFILE_PATTERN_my-layer := "^${LAYERDIR}/"
BBFILE_PRIORITY_my-layer = "10"

recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 1):

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://defconfig \
 "

recipes-kernel/linux/linux-mainline-3.8/defconfig (scenario 1):

http://pastebin.com/qd8B3C5K


recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 2):

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://config-addons.cfg \
 "

recipes-kernel/linux/linux-mainline-3.8/config-addons.cfg
(scenario 2):

CONFIG_WATCHDOG_NOWAYOUT=y

CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y



Results:

  * Scenario 1: Full defconfig replacement

${WORKDIR}/defconfig comes from meta-beagleboard instead of meta-mine

${S}/.config comes from meta-beagleboard instead of meta-mine

  * Scenario 2: Config fragments

"bitbake linux-mainline" got stuck on do_patch

log.do_patch:

DEBUG: Executing shell function do_patch

WARNING: no meta data branch found ...

Switched to branch 'linux-3.8.y'

[INFO] validating against known patches
 (beaglebone-standard-meta)



Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


2013/10/29 Diego Sueiro >


2013/10/29 Andrea Adami mailto:andrea.ad...@gmail.com>>

I'll jump in one more time...

Have you tried putting defconfig and patch under  subdir?

recipes-kernel/linux/linux-yocto-3.2/
defconfig
my-own.patch

I've recently added two similar entries for 3.10 and it works.
Afaik it was impossible to put a common patch under
/linux-yocto-.3.2
at the time.


Andrea,

I did it before and not worked.
I'll do it again just to make sure.


Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


2013/10/29 Andrea Adami mailto:andrea.ad...@gmail.com>>

On Tue, Oct 29, 2013 at 11:33 AM, Diego Sueiro
mailto:diego.sue...@gmail.com>> wrote:
>
> 2013/10/28 Bruce Ashfield mailto:bruce.ashfi...@windriver.com>>
>>
>> I'm using dylan for my yocto checkout (not oe-core
standalone, since
>> this is a yocto list/question),
>
> I thought that opemenbedded-core and poky were sharing the
same core
> components, classes and functions.
>
>>
>> My build shows:
>>
>> meta
>> meta-yocto
>> meta-yocto-bsp=
"dylan:3dc4505f0e744177ae4ddff1e1ce8b31b95dfaa6"
>> meta-ti   =
"master:c14c386946e1ea341faeea292580e37d538d645d"
>> meta-alphalem =
"master:a5c0e8ff51297a4090cd47d669b4fc9c94696908"
>> meta-alphalem-bsp =
"master:56086e4dc618e975c9a46491793041f0d18e47a2"
>>
>> Mike indicated that he was using dylan for meta-ti, but
that doesn't
>> make a difference either, since for our purposed. It's
kernel.bbclass
>> and the yocto kernel processing that ma

Re: [yocto] Getting a relocate_sdk.py issue when installing a sdk on Centos

2013-10-30 Thread Brian Hutchinson 
On Wed, Oct 30, 2013 at 1:41 AM, Laurentiu Palcu
wrote:

> ^
> This commit:
>
> commit 39356f622d3d2226f12c4930beeaf4b392d90ca5
> Author: Konrad Scherer 
> Date:   Thu Oct 17 10:17:20 2013 -0400
>
> relocate_sdk.py: Allow script to work with Python 2.4 and 3.
>
> should fix your issue.
>
> Thanks,
> Laurentiu
>

Hi Laurentiu,

Which git repo?  I couldn't find it?   Is this contrib or mainline?

Regards,

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

Re: [yocto] Getting a relocate_sdk.py issue when installing a sdk on Centos

2013-10-30 Thread Laurentiu Palcu 
On Wed, Oct 30, 2013 at 09:19:56AM -0400, Brian Hutchinson wrote:
> On Wed, Oct 30, 2013 at 1:41 AM, Laurentiu Palcu 
> wrote:
> 
> ^
> This commit:
> 
> commit 39356f622d3d2226f12c4930beeaf4b392d90ca5
> Author: Konrad Scherer 
> Date:   Thu Oct 17 10:17:20 2013 -0400
> 
> relocate_sdk.py: Allow script to work with Python 2.4 and 3.
> 
> should fix your issue.
> 
> Thanks,
> Laurentiu
> 
> 
> Hi Laurentiu,
> 
> Which git repo?  I couldn't find it?   Is this contrib or mainline?
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=39356f622d3d2226f12c4930beeaf4b392d90ca5

or

http://cgit.openembedded.org/openembedded-core/commit/?id=1e2ec5f576f167673d7980737826987fefdc74a9

Laurentiu
> 
> Regards,
> 
> Brian
> 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom defconfig is not used

2013-10-30 Thread Bruce Ashfield 

On 13-10-29 11:31 AM, Diego Sueiro wrote:

Bruce,

I've created new build setup with this configuration:

BB_VERSION= "1.18.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.10"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "beaglebone"
DISTRO= "poky"
DISTRO_VERSION= "1.4.2"
TUNE_FEATURES = "armv7a vfp neon"
TARGET_FPU= "vfp-neon"
meta
meta-yocto
meta-yocto-bsp= "dylan:4e399f08d596197859214fdb3b06403b87bf8789"
meta-oe   = "dylan:a108b2203a997634f87ac687e81712badaf3c546"
common-bsp= "dylan:7fdf9c670a10c5031a2dc15c45e453de8c21"
meta-mine = "dylan:4e399f08d596197859214fdb3b06403b87bf8789"

common-bsp comes from meta-beagleboard.
meta-oe needed to be added because of machine_kernel_pr.bbclass.

bblayers.conf:

LCONF_VERSION = "6"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
  ${TOPDIR}/meta \
  ${TOPDIR}/meta-yocto \
  ${TOPDIR}/meta-yocto-bsp \
${TOPDIR}/meta-openembedded/meta-oe \
  ${TOPDIR}/meta-beagleboard/common-bsp \
  ${TOPDIR}/meta-mine \
  "

meta-mine:

conf/layer.conf:

BBPATH .= ":${LAYERDIR}"
BBFILES += "${LAYERDIR}/recipes*/*/*.bb
${LAYERDIR}/recipes*/*/*.bbappend"
BBFILE_COLLECTIONS += "my-layer"
BBFILE_PATTERN_my-layer := "^${LAYERDIR}/"
BBFILE_PRIORITY_my-layer = "10"

recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 1):

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://defconfig \
 "

recipes-kernel/linux/linux-mainline-3.8/defconfig (scenario 1):

http://pastebin.com/qd8B3C5K


recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 2):

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://config-addons.cfg \
 "

recipes-kernel/linux/linux-mainline-3.8/config-addons.cfg
(scenario 2):

CONFIG_WATCHDOG_NOWAYOUT=y

CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y



Results:

  * Scenario 1: Full defconfig replacement

${WORKDIR}/defconfig comes from meta-beagleboard instead of meta-mine

${S}/.config comes from meta-beagleboard instead of meta-mine



I've confirmed this behaviour on dylan when I exactly reproduced
your configuration. The more interesting one is scenario 2, so I'm
trying it out, before looking at #1 in more detail.

Bruce


  * Scenario 2: Config fragments

"bitbake linux-mainline" got stuck on do_patch

log.do_patch:

DEBUG: Executing shell function do_patch

WARNING: no meta data branch found ...

Switched to branch 'linux-3.8.y'

[INFO] validating against known patches
 (beaglebone-standard-meta)



Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


2013/10/29 Diego Sueiro >


2013/10/29 Andrea Adami mailto:andrea.ad...@gmail.com>>

I'll jump in one more time...

Have you tried putting defconfig and patch under  subdir?

recipes-kernel/linux/linux-yocto-3.2/
defconfig
my-own.patch

I've recently added two similar entries for 3.10 and it works.
Afaik it was impossible to put a common patch under
/linux-yocto-.3.2
at the time.


Andrea,

I did it before and not worked.
I'll do it again just to make sure.


Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


2013/10/29 Andrea Adami mailto:andrea.ad...@gmail.com>>

On Tue, Oct 29, 2013 at 11:33 AM, Diego Sueiro
mailto:diego.sue...@gmail.com>> wrote:
>
> 2013/10/28 Bruce Ashfield mailto:bruce.ashfi...@windriver.com>>
>>
>> I'm using dylan for my yocto checkout (not oe-core
standalone, since
>> this is a yocto list/question),
>
> I thought that opemenbedded-core and poky were sharing the
same core
> components, classes and functions.
>
>>
>> My build shows:
>>
>> meta
>> meta-yocto
>> meta-yocto-bsp=
"dylan:3dc4505f0e744177ae4ddff1e1ce8b31b95dfaa6"
>> meta-ti   =
"master:c14c386946e1ea341faeea292580e37d538d645d"
>> meta-alphalem =
"master:a5c0e8ff51297a4090cd47d669b4fc9c94696908"
>> meta-alphalem-bsp =
"master:56086e4dc618e975c9a46491793041f0d18e47a2"
>>
>> Mike indicated that he was using dylan for meta-ti, but
that doesn't
>> make a difference either, since for our purposed. It's
kernel.bbclass
>> and the yocto kernel processing that matters.

Re: [yocto] Getting a relocate_sdk.py issue when installing a sdk on Centos

2013-10-30 Thread Brian Hutchinson 
On Oct 30, 2013 9:36 AM, "Laurentiu Palcu" 
wrote:
>
> On Wed, Oct 30, 2013 at 09:19:56AM -0400, Brian Hutchinson wrote:
> > On Wed, Oct 30, 2013 at 1:41 AM, Laurentiu Palcu <
laurentiu.pa...@intel.com>
> > wrote:
> >
> > ^
> > This commit:
> >
> > commit 39356f622d3d2226f12c4930beeaf4b392d90ca5
> > Author: Konrad Scherer 
> > Date:   Thu Oct 17 10:17:20 2013 -0400
> >
> > relocate_sdk.py: Allow script to work with Python 2.4 and 3.
> >
> > should fix your issue.
> >
> > Thanks,
> > Laurentiu
> >
> >
> > Hi Laurentiu,
> >
> > Which git repo?  I couldn't find it?   Is this contrib or mainline?
>
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=39356f622d3d2226f12c4930beeaf4b392d90ca5
>
> or
>
>
http://cgit.openembedded.org/openembedded-core/commit/?id=1e2ec5f576f167673d7980737826987fefdc74a9
>
> Laurentiu
> >
> > Regards,
> >
> > Brian
> >

Thanks!  I don't know why my searches didn't find that.

Helps to read the release notes ... I wonder if I shouldn't also make folks
with these older Centos boxes also install buildtools-tarball so everyone
has the same rev of Python etc.  That might make the SDK install go better
too.

Regards,

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

Re: [yocto] Custom defconfig is not used

2013-10-30 Thread Diego Sueiro 
2013/10/30 Bruce Ashfield 

> I've confirmed this behaviour on dylan when I exactly reproduced
> your configuration. The more interesting one is scenario 2, so I'm
> trying it out, before looking at #1 in more detail.
>
Phew, now I'm not feeling crazy.

Looking at linux.inc from meta-beagleboard I can see that there are a lot
of tweaks applied onto kernel config. Maybe it is bricking something.
https://github.com/beagleboard/meta-beagleboard/blob/dylan/common-bsp/recipes-kernel/linux/linux.inc


Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] Add recipe to build the MCS refpolicy.

2013-10-30 Thread Joe MacDonald 
I like both this and your follow-up changes, I'd been thinking it was
time to do such a cleanup myself the other day.  So thanks.  :-)

I just had two small things.  One here, one over on the common.inc file.

[[yocto] [meta-selinux][PATCH] Add recipe to build the MCS refpolicy.] On 
13.10.29 (Tue 23:44) Philip Tricca wrote:

> This is the default policy type used by most (all?) distros that
> support SELinux.
> 
> Signed-off-by: Philip Tricca 
> ---
>  .../refpolicy/refpolicy-mcs_2.20130424.bb  |   23 
> 
>  1 file changed, 23 insertions(+)
>  create mode 100644 recipes-security/refpolicy/refpolicy-mcs_2.20130424.bb
> 
> diff --git a/recipes-security/refpolicy/refpolicy-mcs_2.20130424.bb 
> b/recipes-security/refpolicy/refpolicy-mcs_2.20130424.bb
> new file mode 100644
> index 000..38b78f1
> --- /dev/null
> +++ b/recipes-security/refpolicy/refpolicy-mcs_2.20130424.bb
> @@ -0,0 +1,23 @@
> +SUMMARY = "MCS (Multi Category Security) variant of the SELinux policy"
> +DESCRIPTION = "\
> +This is the reference policy for SE Linux built with MCS support. \
> +An MCS policy is the same as an MLS policy but with only one sensitivity \
> +level. This is useful on systems where a hierarchical policy (MLS) isn't \
> +needed (pretty much all systems) but the non-hierarchical categories are. \
> +"
> +
> +PR = "r0"

I don't think we need this, even for the sake of clarity.

-J.

> +
> +POLICY_NAME = "mcs"
> +POLICY_TYPE = "mcs"
> +POLICY_DISTRO = "redhat"
> +POLICY_UBAC = "n"
> +POLICY_UNK_PERMS = "allow"
> +POLICY_DIRECT_INITRC = "n"
> +POLICY_MONOLITHIC = "n"
> +POLICY_CUSTOM_BUILDOPT = ""
> +POLICY_QUIET = "y"
> +
> +POLICY_MCS_CATS = "1024"
> +
> +include refpolicy_${PV}.inc
-- 
-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/4] Move common POLICY_* variables to refpolicy_common.inc

2013-10-30 Thread Joe MacDonald 
[[yocto] [meta-selinux][PATCH 1/4] Move common POLICY_* variables to 
refpolicy_common.inc] On 13.10.30 (Wed 01:11) Philip Tricca wrote:

> Use default assignment to allow variables to be overriden by recipes
> that include refpolicy_common.inc
> 
> Signed-off-by: Philip Tricca 
> ---
>  recipes-security/refpolicy/refpolicy_common.inc |   12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/recipes-security/refpolicy/refpolicy_common.inc 
> b/recipes-security/refpolicy/refpolicy_common.inc
> index 0ca0b9d..65d679b 100644
> --- a/recipes-security/refpolicy/refpolicy_common.inc
> +++ b/recipes-security/refpolicy/refpolicy_common.inc
> @@ -24,6 +24,18 @@ inherit autotools pythonnative
>  
>  PARALLEL_MAKE = ""
>  
> +POLICY_NAME ?= "${POLICY_TYPE}"
> +POLICY_DISTRO ?= "redhat"
> +POLICY_UBAC ?= "n"
> +POLICY_UNK_PERMS ?= "allow"
> +POLICY_DIRECT_INITRC ?= "n"
> +POLICY_MONOLITHIC ?= "n"
> +POLICY_CUSTOM_BUILDOPT ?= ""
> +POLICY_QUIET ?= "y"
> +POLICY_MLS_SENS = "16"
> +POLICY_MLS_CATS = "1024"
> +POLICY_MCS_CATS = "1024"

Any reason not to make these last three soft assignments as well?
They're unlikely to change and putting them here makes sense, but I can
also imagine someone wanting to use this as a base for creating a
simplified policy.

-J.

> +
>  EXTRA_OEMAKE += "NAME=${POLICY_NAME} \
>   TYPE=${POLICY_TYPE} \
>   DISTRO=${POLICY_DISTRO} \
-- 
-Joe MacDonald.
:wq


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

Re: [yocto] Custom defconfig is not used

2013-10-30 Thread Bruce Ashfield 

On 13-10-29 11:31 AM, Diego Sueiro wrote:

Bruce,

I've created new build setup with this configuration:

BB_VERSION= "1.18.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.10"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "beaglebone"
DISTRO= "poky"
DISTRO_VERSION= "1.4.2"
TUNE_FEATURES = "armv7a vfp neon"
TARGET_FPU= "vfp-neon"
meta
meta-yocto
meta-yocto-bsp= "dylan:4e399f08d596197859214fdb3b06403b87bf8789"
meta-oe   = "dylan:a108b2203a997634f87ac687e81712badaf3c546"
common-bsp= "dylan:7fdf9c670a10c5031a2dc15c45e453de8c21"
meta-mine = "dylan:4e399f08d596197859214fdb3b06403b87bf8789"

common-bsp comes from meta-beagleboard.
meta-oe needed to be added because of machine_kernel_pr.bbclass.

bblayers.conf:

LCONF_VERSION = "6"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
  ${TOPDIR}/meta \
  ${TOPDIR}/meta-yocto \
  ${TOPDIR}/meta-yocto-bsp \
${TOPDIR}/meta-openembedded/meta-oe \
  ${TOPDIR}/meta-beagleboard/common-bsp \
  ${TOPDIR}/meta-mine \
  "

meta-mine:

conf/layer.conf:

BBPATH .= ":${LAYERDIR}"
BBFILES += "${LAYERDIR}/recipes*/*/*.bb
${LAYERDIR}/recipes*/*/*.bbappend"
BBFILE_COLLECTIONS += "my-layer"
BBFILE_PATTERN_my-layer := "^${LAYERDIR}/"
BBFILE_PRIORITY_my-layer = "10"

recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 1):

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://defconfig \
 "

recipes-kernel/linux/linux-mainline-3.8/defconfig (scenario 1):

http://pastebin.com/qd8B3C5K


recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 2):

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
SRC_URI += " file://config-addons.cfg \
 "

recipes-kernel/linux/linux-mainline-3.8/config-addons.cfg
(scenario 2):

CONFIG_WATCHDOG_NOWAYOUT=y

CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y



Results:

  * Scenario 1: Full defconfig replacement

${WORKDIR}/defconfig comes from meta-beagleboard instead of meta-mine

${S}/.config comes from meta-beagleboard instead of meta-mine

  * Scenario 2: Config fragments

"bitbake linux-mainline" got stuck on do_patch

log.do_patch:

DEBUG: Executing shell function do_patch

WARNING: no meta data branch found ...

Switched to branch 'linux-3.8.y'

[INFO] validating against known patches
 (beaglebone-standard-meta)



 AND, I can see this now as well. So you are definitely seeing a bug,
give me a few hours and I'll spin a fix, or find out what is configured
wrong and catch it before it causes problems.

Bruce




Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


2013/10/29 Diego Sueiro >


2013/10/29 Andrea Adami mailto:andrea.ad...@gmail.com>>

I'll jump in one more time...

Have you tried putting defconfig and patch under  subdir?

recipes-kernel/linux/linux-yocto-3.2/
defconfig
my-own.patch

I've recently added two similar entries for 3.10 and it works.
Afaik it was impossible to put a common patch under
/linux-yocto-.3.2
at the time.


Andrea,

I did it before and not worked.
I'll do it again just to make sure.


Regards,

--
*dS
Diego Sueiro

/*long live rock 'n roll*/


2013/10/29 Andrea Adami mailto:andrea.ad...@gmail.com>>

On Tue, Oct 29, 2013 at 11:33 AM, Diego Sueiro
mailto:diego.sue...@gmail.com>> wrote:
>
> 2013/10/28 Bruce Ashfield mailto:bruce.ashfi...@windriver.com>>
>>
>> I'm using dylan for my yocto checkout (not oe-core
standalone, since
>> this is a yocto list/question),
>
> I thought that opemenbedded-core and poky were sharing the
same core
> components, classes and functions.
>
>>
>> My build shows:
>>
>> meta
>> meta-yocto
>> meta-yocto-bsp=
"dylan:3dc4505f0e744177ae4ddff1e1ce8b31b95dfaa6"
>> meta-ti   =
"master:c14c386946e1ea341faeea292580e37d538d645d"
>> meta-alphalem =
"master:a5c0e8ff51297a4090cd47d669b4fc9c94696908"
>> meta-alphalem-bsp =
"master:56086e4dc618e975c9a46491793041f0d18e47a2"
>>
>> Mike indicated that he was using dylan for meta-ti, but
that doesn't
>> make a difference either, since for our purposed. It's
kernel.bbclass
>> and the yocto kernel processing that m

Re: [yocto] Getting a relocate_sdk.py issue when installing a sdk on Centos

2013-10-30 Thread Laurentiu Palcu 
On Wed, Oct 30, 2013 at 10:00:14AM -0400, Brian Hutchinson wrote:
> 
> On Oct 30, 2013 9:36 AM, "Laurentiu Palcu"  wrote:
> >
> > On Wed, Oct 30, 2013 at 09:19:56AM -0400, Brian Hutchinson wrote:
> > > On Wed, Oct 30, 2013 at 1:41 AM, Laurentiu Palcu 
> > >  >
> > > wrote:
> > >
> > > ^
> > > This commit:
> > >
> > > commit 39356f622d3d2226f12c4930beeaf4b392d90ca5
> > > Author: Konrad Scherer 
> > > Date:   Thu Oct 17 10:17:20 2013 -0400
> > >
> > > relocate_sdk.py: Allow script to work with Python 2.4 and 3.
> > >
> > > should fix your issue.
> > >
> > > Thanks,
> > > Laurentiu
> > >
> > >
> > > Hi Laurentiu,
> > >
> > > Which git repo?  I couldn't find it?   Is this contrib or mainline?
> > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=
> 39356f622d3d2226f12c4930beeaf4b392d90ca5
> >
> > or
> >
> > http://cgit.openembedded.org/openembedded-core/commit/?id=
> 1e2ec5f576f167673d7980737826987fefdc74a9
> >
> > Laurentiu
> > >
> > > Regards,
> > >
> > > Brian
> > >
> 
> Thanks!  I don't know why my searches didn't find that.
> 
> Helps to read the release notes ... I wonder if I shouldn't also make folks
> with these older Centos boxes also install buildtools-tarball so everyone has
> the same rev of Python etc.  That might make the SDK install go better too.
If those folks are just users of the SDK then I don't think this is
necessary, provided that the one that generated the SDK tarball had the fix
installed.

Laurentiu

> 
> Regards,
> 
> Brian
> 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Getting a relocate_sdk.py issue when installing a sdk on Centos

2013-10-30 Thread Brian Hutchinson 
On Wed, Oct 30, 2013 at 10:41 AM, Laurentiu Palcu  wrote:

>
> > Helps to read the release notes ... I wonder if I shouldn't also make
> folks
> > with these older Centos boxes also install buildtools-tarball so
> everyone has
> > the same rev of Python etc.  That might make the SDK install go better
> too.
> If those folks are just users of the SDK then I don't think this is
> necessary, provided that the one that generated the SDK tarball had the fix
> installed.
>
>
Yes, they are just using the generated SDK.

Thanks for putting me onto this patch, I'm looking at it now.

Regards,

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

Re: [yocto] [meta-selinux][PATCH 1/4] Move common POLICY_* variables to refpolicy_common.inc

2013-10-30 Thread Philip Tricca 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/30/2013 10:22 AM, Joe MacDonald wrote:
> [[yocto] [meta-selinux][PATCH 1/4] Move common POLICY_* variables
> to refpolicy_common.inc] On 13.10.30 (Wed 01:11) Philip Tricca
> wrote:
> 
>> Use default assignment to allow variables to be overriden by
>> recipes that include refpolicy_common.inc
>> 
>> Signed-off-by: Philip Tricca  --- 
>> recipes-security/refpolicy/refpolicy_common.inc |   12
>>  1 file changed, 12 insertions(+)
>> 
>> diff --git a/recipes-security/refpolicy/refpolicy_common.inc
>> b/recipes-security/refpolicy/refpolicy_common.inc index
>> 0ca0b9d..65d679b 100644 ---
>> a/recipes-security/refpolicy/refpolicy_common.inc +++
>> b/recipes-security/refpolicy/refpolicy_common.inc @@ -24,6 +24,18
>> @@ inherit autotools pythonnative
>> 
>> PARALLEL_MAKE = ""
>> 
>> +POLICY_NAME ?= "${POLICY_TYPE}" +POLICY_DISTRO ?= "redhat" 
>> +POLICY_UBAC ?= "n" +POLICY_UNK_PERMS ?= "allow" 
>> +POLICY_DIRECT_INITRC ?= "n" +POLICY_MONOLITHIC ?= "n" 
>> +POLICY_CUSTOM_BUILDOPT ?= "" +POLICY_QUIET ?= "y" 
>> +POLICY_MLS_SENS = "16" +POLICY_MLS_CATS = "1024" 
>> +POLICY_MCS_CATS = "1024"
> 
> Any reason not to make these last three soft assignments as well? 
> They're unlikely to change and putting them here makes sense, but I
> can also imagine someone wanting to use this as a base for creating
> a simplified policy.

Agree these should be default assignment as well. This was just an
oversight on my part. Good catch & thanks.

- - Philip

>> + EXTRA_OEMAKE += "NAME=${POLICY_NAME} \ TYPE=${POLICY_TYPE} \ 
>> DISTRO=${POLICY_DISTRO} \

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCgAGBQJScRyPAAoJEDL3fnXC4dO6jhsP/RN8oRzJM2Hv2EYBFBQD8lB3
diOfg13xNye7shlmWUmhHppdR41eiTRQS7ozpzrZz7XsI1RFhB7Zeav9R/uRuqZa
+UkXMg0SF979Qpd1MjjFMl9itlUVFvtZsLdXQCB/OmXQB2Z/YL559UTvR/rD+RUd
qqOpRCgZrwo87O9qn4gVMktd4eG+ETyxgzaDO+BNTAmSLqO8kcxDqd3+UsBT8z/9
4P4UsAGStJNPNDpk4lUoZSZDQUtQNQjGgX3iA0mhzfO1MQ4k6zLq6cAT8Bdov8r+
4nRTHFF8WlrI6cjvjy07ffw7QrIu6Gg9m6krdXYapMYThOf7WEVU1g5uFQr4nget
VEC9Zcz6s3oRppGLDYR28scTCaNqiKyiA5CzQ3GsmhgtZVXBw0k2RBW9vNqrwdgi
rYkq523tKX7sj6WM2+leDp6GtgB6qwNqMlHT4UWMeoDdLvXc6blxZbtWhLqdEp7L
Escohx5biH7zLHrgoDHRmkvobQ4g1pP9k8MRgZIKWQ56vmPVrmvN7O3Uj9jenIk6
RcbFQhlwVhXBdRCJxCbejRRIZ1yvWFTGI/yEJ0UgHlYgE0eBFbOnyxDK/f835Ybs
pPhQCoRbetfcB1GkB9T+wxj2IP+RmXVQI7rm2SAs9IjFy3TDndKds/A9z1LJkXCa
QtMLQtTkd+o1cOTg7HLK
=QCzZ
-END PGP SIGNATURE-
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Resend: PATCH] ncurses-terminfo: Remove bashism from basic terminfo installation

2013-10-30 Thread Saul Wold 


I have it pending in the Master under test branch, normally patches to 
the core (meta) go to the openembedded-c...@lists.openembedded.org


Thanks
Sau!


On 10/30/2013 05:16 AM, Seth Bollinger wrote:

The vtX terminfo files aren't being copied on systems where bash isn't
the default shell (debian, etc.).  I removed the bash specific syntax
so the files are properly copied on these systems.

Signed-off-by: Seth Bollinger 
---
  meta/recipes-core/ncurses/ncurses.inc |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/ncurses/ncurses.inc 
b/meta/recipes-core/ncurses/ncurses.inc
index 671daf8..01cdf13 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -174,7 +174,7 @@ shell_do_install() {

  # include some basic terminfo files
  # stolen ;) from gentoo and modified a bit
-for x in ansi console dumb linux rxvt screen sun 
vt{52,100,102,200,220} xterm-color xterm-xfree86 xterm-256color
+for x in ansi console dumb linux rxvt screen sun vt52 vt100 vt102 
vt200 vt220 xterm-color xterm-xfree86 xterm-256color
  do
  local termfile="$(find "${D}${datadir}/terminfo/" -name "${x}" 
2>/dev/null)"
  local basedir="$(basename $(dirname "${termfile}"))"


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

[yocto] opkg git and download hosting

2013-10-30 Thread Paul Barker 
Hi all,

I'm looking at moving opkg away from Subversion hosted on Google Code
to Git hosted elsewhere. Google Code is also closing the downloads
service to new files after January so we'll need somewhere else to put
tarballs of opkg releases. It's previously been mentioned that The
Yocto Project may be able to help us with this. I've got a few
questions on how this would work if we can do it. Is there anyone in
particular I need to talk to or should we just discuss this on list?

Thanks,

-- 
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] adding a udev entry for a camera

2013-10-30 Thread Edward Vidal 
Hello,
I am trying to add a c920 camera to my systems.  I am not getting a
/dev/video0.
lsusb --verbose shows the HD Pro Webcam C920
Bus 001 Device 007: ID 046d:082d Logitech, Inc.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 ?
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  idVendor   0x046d Logitech, Inc.
  idProduct  0x082d
  bcdDevice0.11
  iManufacturer   0
  iProduct2 HD Pro Webcam C920
  iSerial 1 211EF9AF
  bNumConfigurations  1
plus much more information

I created /etc/udev/rules.d/10-c920.rules
SUBSYSTEM=="video4linux", BUS=="usb", ATTRS{idvendor}=="0x046d",
ATTRS{idProduct}=="0x082d", NAME="video0", MODE:="0660"

mknod /dev/video0 c 81 0

when I v4l2-ctl --all error no /dev/video0
Any and all help will be appreciated.
Thanks
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Getting a relocate_sdk.py issue when installing a sdk on Centos

2013-10-30 Thread Brian Hutchinson 
On Oct 30, 2013 10:45 AM, "Brian Hutchinson"  wrote:
>
> On Wed, Oct 30, 2013 at 10:41 AM, Laurentiu Palcu <
laurentiu.pa...@intel.com> wrote:
>>
>>
>> > Helps to read the release notes ... I wonder if I shouldn't also make
folks
>> > with these older Centos boxes also install buildtools-tarball so
everyone has
>> > the same rev of Python etc.  That might make the SDK install go better
too.
>> If those folks are just users of the SDK then I don't think this is
>> necessary, provided that the one that generated the SDK tarball had the
fix
>> installed.
>>
>
> Yes, they are just using the generated SDK.
>
> Thanks for putting me onto this patch, I'm looking at it now.
>
> Regards,
>
> Brian
>
>

Thanks!  That patch fixed both the i686 and x86_64 versions of my SDK!

You are the man!

Regards,

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

Re: [yocto] filling in the "missing" entries in the ref manual variable glossary

2013-10-30 Thread Khem Raj 
On Thu, Oct 24, 2013 at 8:39 AM, Robert P. J. Day  wrote:
>
>   expecting the standard reaction to be, "hey, feel free to submit a
> patch :-)", i've noticed that there are (unsurprisingly) quite a
> number of variables missing from the variable glossary in the ref
> manual.

well I have a different response as alternative file a bug in YP bugzilla :)

>
>   just related to u-boot (which i've been messing with this morning),
> here's the current situation:
>
> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-U
>
> and what seems to be missing is:
>
>   * UBOOT_ARCH
>   * UBOOT_SUFFIX
>   * UBOOT_BINARY
>   * UBOOT_IMAGE
>   * UBOOT_MAKE_TARGET
>   * UBOOT_SYMLINK
>
> short of submitting full patches for things like this, is there at
> least a list we can keep track of this stuff on? i'm not sure i have
> the time to submit full explanatory patches for everything i run
> across, but i can at least report what's missing if that's useful.
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] adding a udev entry for a camera

2013-10-30 Thread Khem Raj 
On Wed, Oct 30, 2013 at 1:51 PM, Edward Vidal  wrote:
> Hello,
> I am trying to add a c920 camera to my systems.  I am not getting a
> /dev/video0.
> lsusb --verbose shows the HD Pro Webcam C920
> Bus 001 Device 007: ID 046d:082d Logitech, Inc.
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass  239 Miscellaneous Device
>   bDeviceSubClass 2 ?
>   bDeviceProtocol 1 Interface Association
>   bMaxPacketSize064
>   idVendor   0x046d Logitech, Inc.
>   idProduct  0x082d
>   bcdDevice0.11
>   iManufacturer   0
>   iProduct2 HD Pro Webcam C920
>   iSerial 1 211EF9AF
>   bNumConfigurations  1
> plus much more information
>
> I created /etc/udev/rules.d/10-c920.rules
> SUBSYSTEM=="video4linux", BUS=="usb", ATTRS{idvendor}=="0x046d",
> ATTRS{idProduct}=="0x082d", NAME="video0", MODE:="0660"
>
> mknod /dev/video0 c 81 0
>
> when I v4l2-ctl --all error no /dev/video0
> Any and all help will be appreciated.

you can check if udev rule is infact kicking in. use udevadm monitor/test

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

[yocto] [meta-selinux][PATCH 1/3] Add RDEPENDS to selinux-config recipe.

2013-10-30 Thread Philip Tricca 
These dependencies contain the utilities required for the selinux init
script to function properly.

Signed-off-by: Philip Tricca 
---
 recipes-security/selinux/selinux-config_0.1.bb |8 
 1 file changed, 8 insertions(+)

diff --git a/recipes-security/selinux/selinux-config_0.1.bb 
b/recipes-security/selinux/selinux-config_0.1.bb
index 6af9c54..27d9995 100644
--- a/recipes-security/selinux/selinux-config_0.1.bb
+++ b/recipes-security/selinux/selinux-config_0.1.bb
@@ -12,6 +12,14 @@ PR = "r3"
 
 SRC_URI = "file://selinux-init.sh"
 
+RDEPENDS_${PN} = " \
+coreutils \
+libselinux-bin \
+policycoreutils-fixfiles \
+policycoreutils-secon \
+policycoreutils-setfiles \
+"
+
 inherit update-rc.d
 
 INITSCRIPT_NAME = "0selinux-init"
-- 
1.7.10.4

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

[yocto] [meta-selinux][PATCH 3/3] Remove unnecessary packages from packagegroup-core-selinux.

2013-10-30 Thread Philip Tricca 
The libraries are pulled in by dependencies and it doesn't make much
sense to have the compiler in an image.

Signed-off-by: Philip Tricca 
---
 recipes-security/packagegroups/packagegroup-core-selinux.bb |7 ---
 1 file changed, 7 deletions(-)

diff --git a/recipes-security/packagegroups/packagegroup-core-selinux.bb 
b/recipes-security/packagegroups/packagegroup-core-selinux.bb
index 76863b0..6f01af9 100644
--- a/recipes-security/packagegroups/packagegroup-core-selinux.bb
+++ b/recipes-security/packagegroups/packagegroup-core-selinux.bb
@@ -11,13 +11,6 @@ PACKAGES = "\
 ALLOW_EMPTY_${PN} = "1"
 
 RDEPENDS_${PN} = " \
-   ustr \
-   libsepol \
-   libsepol-bin \
-   libselinux \
-   libselinux-bin \
-   libsemanage \
-   checkpolicy \
sepolgen \
packagegroup-selinux-policycoreutils \
setools \
-- 
1.7.10.4

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

[yocto] [meta-selinux][PATCH 2/3] Remove unnecessary dependencies from minimal packagegroup.

2013-10-30 Thread Philip Tricca 

Signed-off-by: Philip Tricca 
---
 recipes-security/packagegroups/packagegroup-selinux-minimal.bb |8 
 1 file changed, 8 deletions(-)

diff --git a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb 
b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
index bae15ea..072320d 100644
--- a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
+++ b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
@@ -11,16 +11,8 @@ PACKAGES = "\
 ALLOW_EMPTY_${PN} = "1"
 
 RDEPENDS_${PN} = "\
-   coreutils \
-   libsepol \
-   libselinux \
-   libselinux-bin \
-   libsemanage \
-   policycoreutils-fixfiles \
-   policycoreutils-secon \
policycoreutils-semodule \
policycoreutils-sestatus \
-   policycoreutils-setfiles \
selinux-config \
refpolicy-mls \
 "
-- 
1.7.10.4

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

[yocto] [meta-selinux][PATCH 0/3] Small dependency clean up.

2013-10-30 Thread Philip Tricca 
This series adds the necessary run-time dependencies to the
selinux-config package. Some clean up follows removing the selinux
lib* packages from the packagegroups as they get pulled in by the
utilities anyways.

Philip Tricca (3):
  Add RDEPENDS to selinux-config recipe.
  Remove unnecessary dependencies from minimal packagegroup.
  Remove unnecessary packages from packagegroup-core-selinux.

 recipes-security/packagegroups/packagegroup-core-selinux.bb|7 ---
 recipes-security/packagegroups/packagegroup-selinux-minimal.bb |8 
 recipes-security/selinux/selinux-config_0.1.bb |8 
 3 files changed, 8 insertions(+), 15 deletions(-)

-- 
1.7.10.4

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

Re: [yocto] adding a udev entry for a camera

2013-10-30 Thread Edward Vidal 
Hello,
This is when I connect the camera
udevadm monitor test
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[803.263336] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4 (usb)
KERNEL[803.267456] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.0
(usb)
KERNEL[803.269287] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.1
(usb)
KERNEL[803.269958] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.2
(usb)
KERNEL[803.270721] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.3
(usb)
KERNEL[803.276214] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/usb_device/usbdev1.15
(usb_device)**
UDEV  [803.277191] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4 (usb)
UDEV  [803.306091] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/usb_device/usbdev1.15
(usb_device)
UDEV  [803.318603] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.2
(usb)
UDEV  [803.324249] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.1
(usb)
UDEV  [803.329712] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.0
(usb)
UDEV  [803.333160] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.3
(usb)

still no /dev/video0
ls -la /dev/v*
crw-rw 1 root tty 7,   0 Jan  1  2000 /dev/vcs
crw-rw 1 root tty 7,   1 Jan  1  2000 /dev/vcs1
crw-rw 1 root tty 7,   2 Jan  1  2000 /dev/vcs2
crw-rw 1 root tty 7,   3 Oct 29 13:51 /dev/vcs3
crw-rw 1 root tty 7, 128 Jan  1  2000 /dev/vcsa
crw-rw 1 root tty 7, 129 Jan  1  2000 /dev/vcsa1
crw-rw 1 root tty 7, 130 Jan  1  2000 /dev/vcsa2
crw-rw 1 root tty 7, 131 Oct 29 13:51 /dev/vcsa3
root@beagleboard:~# lsusb
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 0409:0059 NEC Corp. HighSpeed Hub
Bus 001 Device 005: ID 413c:2005 Dell Computer Corp. RT7D50 Keyboard
Bus 001 Device 006: ID 046d:c001 Logitech, Inc. N48/M-BB48 [FirstMouse Plus]
Bus 001 Device 015: ID 046d:082d Logitech, Inc.
***


udevadm monitor --udev
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
camera removed*
UDEV  [1325.916811] remove
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.1
(usb)
UDEV  [1325.918489] remove
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.0
(usb)
UDEV  [1325.919282] remove
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.2
(usb)
UDEV  [1325.923005] remove
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.3
(usb)
UDEV  [1325.928437] remove
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/usb_device/usbdev1.15
(usb_device)
UDEV  [1325.932709] remove
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4 (usb)
camera added
***
UDEV  [1329.344727] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4 (usb)
UDEV  [1329.376313] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/usb_device/usbdev1.16
(usb_device)
UDEV  [1329.389008] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.2
(usb)
UDEV  [1329.396241] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.1
(usb)
UDEV  [1329.401795] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.0
(usb)
UDEV  [1329.406739] add
/devices/platform/usbhs_omap/ehci-omap.0/usb1/1-2/1-2.3/1-2.3.4/1-2.3.4:1.3
(usb)

This is what I get in /var/log/messages
Oct 29 14:17:28 beagleboard user.info kernel: usb 1-2.3.4: USB disconnect,
device number 16
Oct 29 14:17:31 beagleboard user.info kernel: usb 1-2.3.4: new high-speed
USB device number 17 using ehci-omap
Is there anything else that I can test  / provide
Thanks


On Wed, Oct 30, 2013 at 5:58 PM, Khem Raj  wrote:

> On Wed, Oct 30, 2013 at 1:51 PM, Edward Vidal 
> wrote:
> > Hello,
> > I am trying to add a c920 camera to my systems.  I am not getting a
> > /dev/video0.
> > lsusb --verbose shows the HD Pro Webcam C920
> > Bus 001 Device 007: ID 046d:082d Logitech, Inc.
> > Device Descriptor:
> >   bLength18
> >   bDescriptorType 1
> >   bcdUSB   2.00
> >   bDeviceClass  239 Miscellaneous Device
> >   bDeviceSubClass 2 ?
> >   bDeviceProtocol 1 Interface Association
>

Re: [yocto] How to bring up "apt and dpkg" packages on yocto

2013-10-30 Thread Khem Raj 
This seems more of multilib issue with dpkg provided you have
configured multilib correctly in your distro/local.conf for ppc64. One
test would be that you use default packaging/opkg and see if that
works to  isolate the issue

On Mon, Oct 28, 2013 at 8:26 AM, Sandeep G.R  wrote:
> Hi Paul,
>
> I have made those changes as PACKAGE_CLASSES ?= "package_deb"
> IMAGE_FEATURES += "package-management" IMAGE_INSTALL_append += "dpkg" but
> ended with an error and attached a log file for reference. I have attached
> the log for reference.
>
>
> On Mon, Oct 28, 2013 at 5:05 AM, Paul Eggleton
>  wrote:
>>
>> On Tuesday 22 October 2013 08:10:15 Sandeep G.R wrote:
>> >   I have selected PACKAGE_CLASSES ?= "package_rpm package_deb" and
>> > IMAGE_FSTYPE is tar.gz
>>
>> "package_deb" must be listed first in PACKAGE_CLASSES if you wish to use
>> it for
>> constructing your image. You will also need to have "package-management"
>> in
>> IMAGE_FEATURES if you want apt/dpkg and the package manager data to be
>> installed into the image itself.
>>
>> Cheers,
>> Paul
>>
>> --
>>
>> Paul Eggleton
>> Intel Open Source Technology Centre
>
>
>
>
> --
> Thanks & Regards,
> Sandeep G R
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] different EXTRA_OECONF per package based on image recipe

2013-10-30 Thread Khem Raj 
On Mon, Oct 28, 2013 at 2:15 AM, Karl Hiramoto  wrote:
>
> Hi,
>
> In my overlay i have different Machines with different images that are
> built.In a couple of packages i need different autoconf configure args
> based on the  machine or image.

hmm, I would suggest to add PACKAGECONFIG but if you depend on machine
for deciding what options to use then you might turn these recipes
into machine specific and add EXTRA_OECONF_yourmachine = "x y z"
and stuff like that. Try to avoid machine dependencies on generic
recipes as much as you can.

>
> Is the best way to do this via PACKAGECONFIG, create multiple overlays for
> machine1, machine2, machine3, and common? Is there a better way?
>
>
> Is there an example somewhere of different package configurations for
> different images?
>
> thanks
>
> Karl
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] core-image-minimal-dev - linker error : cannot find -lc

2013-10-30 Thread Khem Raj 
On Thu, Oct 24, 2013 at 6:07 AM, Anup Kini  wrote:

> Hi All,
>
> I am trying to compile a c program on core-image-minimal-dev but en up
> with the following error.
> Kindly let me know if i need to include any additional packages in order
> to be able to compile c programs on the image.
>
> /usr/lib/gcc/arm-poky-linux-gnueabi/4.8.1/../../../../arm-poky-linux-gnueabi/bin/ld:
> cannot find -lc
> collect2: error: ld returned 1 exit status
> make: *** [all] Error 1
>


​It seems you are compiling on target. Make sure that you have 'tools-sdk'
packagegroup added to your image ​via IMAGE_FEATURES



>
>
> Build Configuration:
> BB_VERSION   = "1.20.0"
> BUILD_SYS   = "x86_64-linux"
> NATIVELSBSTRING  = "Ubuntu-12.04"
> TARGET_SYS   = "arm-poky-linux-gnueabi"
> MACHINE  = "zc702-zynq7"
> DISTRO = "poky"
> DISTRO_VERSION= "1.5"
> TUNE_FEATURES = " armv7a vfp neon zynq"
> TARGET_FPU   = "vfp-neon"
> meta
> meta-yocto
> meta-yocto-bsp= "origin/dylan:e7a20238dc73bb449f15feaf0dead51daf796184"
> meta-oe   = "origin/dylan:8aafddccb03f54923927e9d1c8c80223baf581de"
> meta-xilinx   =
> "remotes/origin/dylan:21c3cd3f058d736742ebc23a7a954f23456fbea5"
> meta-java = "master:de06956f93ecd15d8c941a05da47a4425e3d397a"
>
>
>
> --
>
> *Anup Kini
> *Systems Engineer
> *
> --
> *
>
> *Synapticon** * |  Cyber-Physical System Solutions 
>
> Mobile:
>
> Direct:
>
> +49 151 / 638 646 73
>
> +49 7335 / 186 999 21
>
> Fax:
> +49 7335 / 186 999 1
>
>
>  **
>
>  
>
> synapticon.com   |  
> @synapticon_co
> 
>
> Synapticon GmbH  |  Hohlbachweg 2  |  73344 Gruibingen, DE
> Secretary +49 7335 / 186 999 0  |  General Manager: Nikolai Ensslen
> Registry Court Ulm HRB 725114  |  USt-ID DE271647127
>
> This message and any files transmitted with it are confidential and
> intended
> solely for the use of the individual or entity to whom they are addressed.
> Please notify the sender immediately if you have received this e-mail by
> mistake and delete it from your system.
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto toolchain build question

2013-10-30 Thread Khem Raj 
On Wed, Oct 23, 2013 at 6:19 AM, jan alexandru vaduva
 wrote:
> Hello,
>
> I have a curiosity:
> Take a toolchain that builds for a 32-bits architecture, but breaks for a
> 64-bits one.
> Is there a way to ensure that when builded with Yocto that toolchain will be
> generated and used to build target specific recipes.

I dont understand the question clearly. But generally the toolchains
are built for native architecture to run on and generate code for
target. for SDK we can generate them to have a different host to run
on and still generate code for same target as internal toolchain.

>
>
>
> Thanks,
> Alex
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Customizing u-boot,kernel and rootfs

2013-10-30 Thread Khem Raj 
On Tue, Oct 22, 2013 at 7:00 AM, Rohit Borse  wrote:
> Hi,
>  I need to customize u-boot, kernel and root file system for my
> Bluegiga-APx4 board using bitbake platform. Does yocto has any documentation
> or steps to configure and build customized BSP using bitbake for
> Bluegiga-APx4 module?

there is lot of information on creating BSPs you can look through the
manual and also wiki and other resources. However if you are looking
preexisting support for your board that may be harder to find.

>
> Regards,
> Rohit Borse
>
> -
> Notice: This message has been scanned by Trend Micro Mail Security scanner
> and is believed to be clean
> -
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto