Re: [yocto] Prescribed way to make global variables in recipes?

2016-04-08 Thread Andre McCurdy 
On Fri, Apr 8, 2016 at 10:22 AM, Andy Gikling  wrote:
> This doesn’t seem to be a viable option.  I’m still missing something I
> think.
>
> We are adding our own layer on top of our soc vendor’s layer.  In their
> layer there is a specialized u-boot recipe for the imx6 we are using.
>
> So I try to make a recipe for uboot (u-boot-faux_2014.04.bb) that includes
> the vendor’s uboot recipe with “include
> recipes-bsp/u-boot/u-boot_2014.04.bb” as suggested and try to build an image
> that is going to IMAGE_INSTALL my customized version of u-boot instead of
> the soc vendor’s.  However, I get an error at bitbake parse time saying:
>
> ERROR: Multiple .bb files are due to be built which each provide u-boot
>
> This makes sense because bitbake sees that yes, in fact now there are two
> recipes that provide u-boot.

I guess the problem here is not that you have two versions of u-boot
but that you are trying to include both of them at once - e.g. one you
added explicitly via IMAGE_INSTALL and one that the machine config
probably added via MACHINE_EXTRA_RDEPENDS or similar. To fix that,
you'll need to find a way to disable the dependency being added via
the machine config (it's not a perfect solution though because if you
then try to build an image to which you have not explicitly added a
u-boot dependency too you'll end up with a build which doesn't contain
any u-boot image at all...).

> I suppose I can do something like use
> “PREFERRED_PROVIDER_u-boot” in my local.conf, but now I need to change my
> local.conf any time I want to build a different image (ie bitbake faux-app
> and bitbake faux-app-debug).  I really want a workflow that doesn’t require
> me to change configuration files, instead just bitbake different image
> recipes.
>
> In this project I also need to conditionally patch the kernel and I’m going
> to have this same problem with multiple kernel providers as well.

If you want to change the kernel too then maybe your best option is
just to define a new machine config (you can use a similar approach as
you used for the u-boot recipe of including the original and then
over-riding just the options you want to change).

Since the machine config is a global config file which affects all
recipes, you can also use it to set the global variables etc you were
planning to use to conditionally apply u-boot patches, so you would no
longer need multiple u-boot recipes or multiple images.

> Also, I
> don’t want to remove our soc vendor’s layer to get around this error.  Their
> layer sets up the machine and all sorts of other things.  If I got rid of it
> I would need to build all that functionality into my project’s layer…  or is
> this what I’m going to need to do?
>
>
>
> Thoughts?
>
>
> ~Andy
>
>
>
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Friday, April 08, 2016 10:10 AM
> To: Andy Gikling
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Prescribed way to make global variables in recipes?
>
>
>
>
>
> On 8 April 2016 at 16:05, Andy Gikling  wrote:
>
> So what do I do in that case? Just make two of my own versions of the
> u-boot_2014.04.bb file, and give them different names?  For example
> “u-boot-faux_2014.04.bb” and “u-boot-faux-debug_2014.04.bb” ?  That should
> work but does that make sense to do?
>
>
> As the stock u-boot appears to be sufficient I'd say use that and then add a
> u-boot-faux-debug_2014.04.bb recipe that just does "include u-boot-${PV}.bb"
> and then whatever SRC_URI changes you want in that version.
>
>
>
> Hopefully you don't need to make any fiddly changes to the recipe as PN is
> now different.
>
>
>
> Ross
>
>
>
>
> --
> ___
> 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] Prescribed way to make global variables in recipes?

2016-04-08 Thread Andy Gikling 
This doesn’t seem to be a viable option.  I’m still missing something I think.

We are adding our own layer on top of our soc vendor’s layer.  In their layer 
there is a specialized u-boot recipe for the imx6 we are using.

So I try to make a recipe for uboot 
(u-boot-faux_2014.04.bb) that includes the 
vendor’s uboot recipe with “include recipes-bsp/u-boot/u-boot_2014.04.bb” as 
suggested and try to build an image that is going to IMAGE_INSTALL my 
customized version of u-boot instead of the soc vendor’s.  However, I get an 
error at bitbake parse time saying:

ERROR: Multiple .bb files are due to be built which each provide u-boot

This makes sense because bitbake sees that yes, in fact now there are two 
recipes that provide u-boot.  I suppose I can do something like use 
“PREFERRED_PROVIDER_u-boot” in my local.conf, but now I need to change my 
local.conf any time I want to build a different image (ie bitbake faux-app and 
bitbake faux-app-debug).  I really want a workflow that doesn’t require me to 
change configuration files, instead just bitbake different image recipes.

In this project I also need to conditionally patch the kernel and I’m going to 
have this same problem with multiple kernel providers as well.  Also, I don’t 
want to remove our soc vendor’s layer to get around this error.  Their layer 
sets up the machine and all sorts of other things.  If I got rid of it I would 
need to build all that functionality into my project’s layer…  or is this what 
I’m going to need to do?

Thoughts?

~Andy

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, April 08, 2016 10:10 AM
To: Andy Gikling
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Prescribed way to make global variables in recipes?


On 8 April 2016 at 16:05, Andy Gikling 
> wrote:
So what do I do in that case? Just make two of my own versions of the 
u-boot_2014.04.bb file, and give them different 
names?  For example “u-boot-faux_2014.04.bb” and 
“u-boot-faux-debug_2014.04.bb” ?  That 
should work but does that make sense to do?

As the stock u-boot appears to be sufficient I'd say use that and then add a 
u-boot-faux-debug_2014.04.bb recipe that 
just does "include u-boot-${PV}.bb" and then whatever SRC_URI changes you want 
in that version.

Hopefully you don't need to make any fiddly changes to the recipe as PN is now 
different.

Ross

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

[yocto] Yocto Project Status WW15

2016-04-08 Thread Jolley, Stephen K 
Current Dev Position: YP 2.1 M4 (Stabilization only milestone.)

Next Deadline: YP 2.1 Final Release Target: April 29, 2016


SWAT team rotation: Saul -> Paul

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

*YP 2.1 M3.rc2 was released

*YP 2.1 release branches ('krogoth') were created and M4.rc1 went into 
QA

*Nobody replied about buildhistory so it would seem nobody cares (or 
nobody reads these reports)?!

*We managed a significant amount of bug closure last week which caused 
WDD to drop for a change however we suspect it may rise again next week.

*There have been a lot of good bugfixes being submitted however the 
rate seems to have significantly tapered off yet more work remains.

*We're starting to think about 2.2, if you have enhancements you'd like 
to see in 2.2, please do make sure the bugzilla has entries for them.


Key YP 2.1 Dates:

YP 2.1 Final Release Target: April 29, 2016 (Still on Track)


Tracking Metrics:

WDD 2566 (last week 2748)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.1_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.1_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.1_Features

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.2_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.2_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.2_Features


[If anyone has suggestions for other information you'd like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:(503) 712-0534
*Cell:   (208) 244-4460
* Email:stephen.k.jol...@intel.com

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

Re: [yocto] Prescribed way to make global variables in recipes?

2016-04-08 Thread Burton, Ross 
On 8 April 2016 at 16:05, Andy Gikling  wrote:

> So what do I do in that case? Just make two of my own versions of the
> u-boot_2014.04.bb file, and give them different names?  For example “
> u-boot-faux_2014.04.bb” and “u-boot-faux-debug_2014.04.bb” ?  That should
> work but does that make sense to do?


As the stock u-boot appears to be sufficient I'd say use that and then add
a u-boot-faux-debug_2014.04.bb recipe that just does "include
u-boot-${PV}.bb" and then whatever SRC_URI changes you want in that version.

Hopefully you don't need to make any fiddly changes to the recipe as PN is
now different.

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

Re: [linux-yocto] Feature branch on linux-yocto-3.14 for Valleyisland

2016-04-08 Thread Bruce Ashfield 

On 04/08/2016 04:07 AM, chong.yi.c...@intel.com wrote:

From: "Chai, Chong Yi" 

Hi Bruce,

The feature branch (additional 66 commits) for enabling Valleyisland are ready 
to be fetched from Github.
This branch is targeted for kernel linux-yocto-3.14.

URL: https://github.com/yoctobsp/linux-yocto-3.14.git
Branch: standard/valleyisland



fetched and merged to linux-yocto-3.14. We now have a standard/valleyisland
branch.

Cheers,

Bruce



Stats:

Andy Shevchenko (9):
   dma: dw: allocate memory in two stages in probe
   dmaengine: dw: enable clock before access
   dmaengine: dw: fix regression in dw_probe() function
   dmaengine: dw: move dw_dmac.h to where it belongs to
   dmaengine: dw: convert dw_dma_slave to use explicit HS interfaces
   dmaengine: dw: apply both HS interfaces and remove slave_id usage
   dmaengine: dw: introduce generic filter function
   dmaengine: dw: move clock operations to platform.c
   serial: 8250: don't use slave_id of dma_slave_config

Antonio Ospite (1):
   spi/pxa2xx: fix runtime PM enabling order

Chew, Chiau Ee (5):
   x86/Kconfig: add PCI dependency for CONFIG_X86_INTEL_LPSS
   x86/byt: enable board file for BYT LPSS PCI mode
   dma: dw: Fix Intel MID DMA driver and Designware DMA driver loading
 sequence
   spi/pxa2xx: change default supported DMA burst size to 1
   spi/pxa2xx: fix incorrect SW mode chipselect setting for BayTrail LPSS
 SPI

Chew, Kean Ho (4):
   pinctrl-baytrail: unmap interrupt when free the gpio pin
   pinctrl-baytrail: enable platform device in the absent of ACPI
 enumeration
   pinctrl-baytrail: setup IOAPIC interrupt for GPIO clusters on non-ACPI
 system
   mmc: sdhci: Force BYT SDCARD host to run with SDR25 mode

Heikki Krogerus (2):
   serial: 8250_pci: remove rts_n override from Baytrail quirk
   ACPI / LPSS: not using UART RTS override with Auto Flow Control

Jingoo Han (1):
   spi: pxa2xx: remove unnecessary OOM messages

Loic Poulain (1):
   8250_dw: Support all baudrates on baytrail

Maurice Petallo (7):
   i2c: allow Designware I2C to be probed before SMBus for Baytrail
   mmc: sdhci: Preset value not supported in Baytrail eMMC
   mmc: sdhci: add DDR50 1.8V mode support for BayTrail eMMC Controller
   serial: 8250_pci: mask UART TX completion intr in byt_set_termios
   serial: 8250_dw: mask UART TX completion intr in byt_set_termios
   serial: 8250_core: handle_irq returns 1 only if data was processed
   thermal: Intel SoC DTS: Don't do thermal zone update inside spin_lock

Mika Westerberg (2):
   spi/pxa2xx: Prevent DMA from transferring too many bytes
   spi/pxa2xx: Don't use slave_id of dma_slave_config

Roger Quadros (1):
   usb: dwc3: core: Fix gadget for system suspend/resume

Sarah Sharp (1):
   usb/xhci: Change how we indicate a host supports Link PM.

Srinivas Pandruvada (1):
   thermal: Intel SoC DTS thermal

Wan Ahmad Zainie (31):
   dmaengine: dw: fix checkpatch.pl warnings
   pinctrl-baytrail: Serialize GPIO registers access with global spinlock
   hpet: refactor driver
   hpet: implement start/stop/query API
   hpet: Fix checkpatch.pl warnings
   i2c: designware: cleanup irq handler setting
   i2c: designware: use hardware-provided Rx/Tx FIFO depths
   i2c: designware: use symbolic names for command bits
   i2c: designware: cleanup __i2c_dw_enable()
   i2c: designware: explicitly abort running operation on disable
   i2c: designware: improve FIFO performance
   i2c: designware: add per-channel speed parameter and fast-plus speed
 option
   i2c: designware: add i2c high-speed support
   i2c: designware: Fix checkpatch.pl warnings
   mmc: block: refactor read-only handling
   mmc: block: implement write request blocking
   mmc: support whole-device temporary write protection over CSD bits
 13:12
   mmc: block: Fix checkpatch.pl warning
   pwm: Add freq_hz and duty_percent
   libata: add curr_xfer_mode attribute
   libata: enable atapi_an by default
   libata: handle HDIO_SET_DMA & HDIO_GET_DMA ioctl
   scsi: add extended information to MEDIA_CHANGE
   serial: 8250: Override the DCD and DSR pin status for Bay Trail
   spi/pxa2xx: auto switch between PIO and DMA with configurable
 threshold size
   spi: modify spidev_test to test automatic PIO/DMA switching
   spi/pxa2xx: Add new ioctl for configuring FIFO trigger level in
 runtime
   spi: modify spidev_test to test modifying FIFO trigger level during
 runtime
   usb: core: hub: Generate uevent for overcurrent event
   usb: core: hub: Fix checkpatch.pl error
   watchdog: iTCO_wdt: Fix checkpatch.pl warnings

  Documentation/spi/spidev_test.c |  74 ++-
  MAINTAINERS |   2 +-
  arch/avr32/mach-at32ap/at32ap700x.c |  17 +-
  arch/avr32/mach-at32ap/include/mach/atmel-mci.h |   2 +-
  arch/x86/Kconfig|   9 +-
  arch/x86/platform/Makefile  |   3 +
  arch/x86/platform/byt/Makefile  |   1 +

Re: [yocto] Prescribed way to make global variables in recipes?

2016-04-08 Thread Andy Gikling 
Ross,

Perfect thank you so much.  That makes total sense now.

I like the idea of just having two different recipes and then use 
IMAGE_INSTALL.  However, in the u-boot example I’m actually just using a 
bbappend to the u-boot recipe provided with our target SOM’s bsp.  Can I select 
different bbappend files in my image recipe with IMAGE_INSTALL?  I don’t think 
so but I’ll try though.

So what do I do in that case? Just make two of my own versions of the 
u-boot_2014.04.bb file, and give them different names?  For example 
“u-boot-faux_2014.04.bb” and “u-boot-faux-debug_2014.04.bb” ?  That should work 
but does that make sense to do?

Thanks again,

~Andy Gikling

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, April 08, 2016 9:44 AM
To: Andy Gikling
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Prescribed way to make global variables in recipes?

On 8 April 2016 at 15:30, Andy Gikling 
> wrote:
Dear Yocto,

First of all, I love this project.  Thanks for all your hard work.

Question:  What is the prescribed way to allow image recipes to make global 
configuration variables that other recipes can use?

You can't.  The basic reason being that images are built from packages, and the 
packages have already been built when the image is built.

Ideally, for CI purposes we would like to allow our CI server to simply call 
“bitbake faux-app” to make a release build and then “bitbake faux-app-debug” to 
make a debug build.  The thought process is I could have a variable defined in 
both “faux-app_0.1.bb” and 
“faux-app-debug_0.1.bb” called FAUX_RELEASE_MODE. 
 In faux-app_0.1.bb this variable would be set to 
“release” and in faux-app-debug_0.1.bb it would 
be set to “debug.”

In your view, what would happen if you did "bitbake faux-app faux-app-debug"?

There are several ways to fix this that don't involve breaking how OE works.  
Either have a rootfs-time postprocess command in the debug image recipe that 
manipulates the installed file system, or have two recipes for the thing that 
changes (in this case u-boot) where one includes the other and makes the 
changes required, and the image install the relevant package (u-boot vs 
u-boot-debug).

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

Re: [yocto] Prescribed way to make global variables in recipes?

2016-04-08 Thread Burton, Ross 
On 8 April 2016 at 15:30, Andy Gikling  wrote:

> Dear Yocto,
>
>
>
> First of all, I love this project.  Thanks for all your hard work.
>
>
>
> Question:  What is the prescribed way to allow image recipes to make
> global configuration variables that other recipes can use?
>
>
You can't.  The basic reason being that images are built from packages, and
the packages have already been built when the image is built.


> Ideally, for CI purposes we would like to allow our CI server to simply
> call “bitbake faux-app” to make a release build and then “bitbake
> faux-app-debug” to make a debug build.  The thought process is I could have
> a variable defined in both “faux-app_0.1.bb” and “faux-app-debug_0.1.bb”
> called FAUX_RELEASE_MODE.  In faux-app_0.1.bb this variable would be set
> to “release” and in faux-app-debug_0.1.bb it would be set to “debug.”
>

In your view, what would happen if you did "bitbake faux-app
faux-app-debug"?

There are several ways to fix this that don't involve breaking how OE
works.  Either have a rootfs-time postprocess command in the debug image
recipe that manipulates the installed file system, or have two recipes for
the thing that changes (in this case u-boot) where one includes the other
and makes the changes required, and the image install the relevant package
(u-boot vs u-boot-debug).

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

[yocto] Prescribed way to make global variables in recipes?

2016-04-08 Thread Andy Gikling 
Dear Yocto,

First of all, I love this project.  Thanks for all your hard work.

Question:  What is the prescribed way to allow image recipes to make global 
configuration variables that other recipes can use?

After extensive research and educating myself on how bitbake works, it seems 
that what I'm asking for is technically not possible.  This issue is discussed 
previously without a clear conclusion in the mailing list:

https://lists.yoctoproject.org/pipermail/yocto/2012-February/004552.html

Another work around is to setup a BB_ENV_EXTRAWHITE variable as described here:

http://stackoverflow.com/questions/17366984/is-it-possible-to-pass-in-command-line-variables-to-a-bitbake-build

However, this doesn't seem like the right approach either.

If there's no way to make global variables in an image recipe it seems one of 
two things are true:  Either bitbake lacks this powerful feature for some 
reason or there's some other "prescribed" way to accomplish what I need and I 
just don't know what that is.  I suspect the latter is true.

Let me give a simple example of why I need this feature.  We are deploying an 
application with Yocto called "faux-app."  Once this product is live, I would 
like to use our continuous integration build mechanism to build images for 
faux-app that contain the latest version of the user space application code.

We have a meta-faux-app layer with a hand full of recipes that are gracefully 
customizing our image.  One of the recipes is an "image recipe" that pulls in 
core-image and builds the output deploy binaries called faux-app_0.1.bb.

Another recipe is essentially a bbappend that is in charge of applying a patch 
to u-boot.  This patch configures u-boot to behave in a "debug" fashion vs a 
"release" fashion (ie, defaulting to network boot for debug and sdcard boot for 
release).

Ideally, for CI purposes we would like to allow our CI server to simply call 
"bitbake faux-app" to make a release build and then "bitbake faux-app-debug" to 
make a debug build.  The thought process is I could have a variable defined in 
both "faux-app_0.1.bb" and "faux-app-debug_0.1.bb" called FAUX_RELEASE_MODE.  
In faux-app_0.1.bb this variable would be set to "release" and in 
faux-app-debug_0.1.bb it would be set to "debug."

Then, in the "u-boot_2014.04.bbappend" file found in our layer, we could append 
the correct patch to the SRC_URI variable using inline python logic for example:

SRC_URI += "${@base_contains('FAUX_RELEASE_MODE', 'release', 
'file://u-boot-mode-release.patch', ' file://u-boot-mode-debug.patch ', d)}"

So in this way I have my image recipe setting a value that tells other recipes 
how to behave.  This seems like a perfectly reasonable use case so I'm at a 
loss as to why bitbake doesn't support this (I understand the environment 
variables is "scrubbed" between recipes - it makes sense).  Is there another 
mechanism I'm not aware of?  Can someone give me an example of a different way 
to accomplish my use case described above?

Any guidance would be much appreciated!  Thanks,

~Andy Gikling


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

Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2

2016-04-08 Thread Alexander Kanavin 

On 04/07/2016 07:58 PM, Chris Trobridge wrote:


http://cgit.openembedded.org/meta-openembedded/tree/meta-python/recipes-devtools/python
 >
 > Will be fixed by deprecating python 2, of course.
 >
 > Alex

Is there a  shorter term solution that's generally applicable, like a
separate python3-gobject recipe?


In principle, yes - if you need to have pygobject both for 2 and 3 at 
the same time, you can have two slightly different recipes; but I don't 
know if it will work. You need to try and see.


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

[yocto] does any YP guide show clearly how to use a local git kernel repo?

2016-04-08 Thread Robert P. J. Day 

  in my travels, i frequently read online about people asking how to
set up a kernel recipe to point at a local kernel source tree or local
kernel git repo and, as best i can tell, this isn't really explained
in any kind of detail in any YP guide, including the kernel
development guide.

  it seems one has to dig around to finally come up with the SRC_URI
setting for cloning a local git repo, as in:

SRC_URI="git:///;protocol=file; ... etc etc ..."

is this described *in detail* in any YP guide? because it's certainly
one of those FAQs.

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

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

2016-04-08 Thread wenzong fan 
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:


/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/selinux/config
 Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot

/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/sysroot-providers/virtual_refpolicy
 Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
Please verify which recipe should provide the above files.

Philip,

Can you consider to withdraw the integration?

Thanks
Wenzong

On 04/04/2016 08:21 AM, Philip Tricca wrote:

With the virutal package there's no need for a separate recipe to build
the config. This can be generated and included as part of the policy
package.

Signed-off-by: Philip Tricca 
---
  .../packagegroups/packagegroup-core-selinux.bb |  1 -
  .../packagegroups/packagegroup-selinux-minimal.bb  |  1 -
  recipes-security/refpolicy/refpolicy_common.inc| 30 ++--
  recipes-security/selinux/selinux-config_0.1.bb | 40 --
  4 files changed, 28 insertions(+), 44 deletions(-)
  delete mode 100644 recipes-security/selinux/selinux-config_0.1.bb

diff --git a/recipes-security/packagegroups/packagegroup-core-selinux.bb 
b/recipes-security/packagegroups/packagegroup-core-selinux.bb
index 62c5a76..c6d22b7 100644
--- a/recipes-security/packagegroups/packagegroup-core-selinux.bb
+++ b/recipes-security/packagegroups/packagegroup-core-selinux.bb
@@ -22,7 +22,6 @@ RDEPENDS_${PN} = " \
packagegroup-selinux-policycoreutils \
setools \
setools-console \
-   selinux-config \
selinux-autorelabel \
selinux-init \
selinux-labeldev \
diff --git a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb 
b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
index 87ae686..451ae8b 100644
--- a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
+++ b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
@@ -21,7 +21,6 @@ RDEPENDS_${PN} = "\
policycoreutils-semodule \
policycoreutils-sestatus \
policycoreutils-setfiles \
-   selinux-config \
selinux-labeldev \
virtual/refpolicy \
  "
diff --git a/recipes-security/refpolicy/refpolicy_common.inc 
b/recipes-security/refpolicy/refpolicy_common.inc
index ba887e4..305675f 100644
--- a/recipes-security/refpolicy/refpolicy_common.inc
+++ b/recipes-security/refpolicy/refpolicy_common.inc
@@ -1,3 +1,5 @@
+DEFAULT_ENFORCING ??= "enforcing"
+
  SECTION = "base"
  LICENSE = "GPLv2"

@@ -14,7 +16,8 @@ SRC_URI += "file://customizable_types \

  S = "${WORKDIR}/refpolicy"

-FILES_${PN} = " \
+CONFFILES_${PN} += "${sysconfdir}/selinux/config"
+FILES_${PN} += " \
${sysconfdir}/selinux/${POLICY_NAME}/ \
${datadir}/selinux/${POLICY_NAME}/*.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

[yocto] [PATCH][meta-selinux] refpolicy-minimum: port changes for prepare_policy_store

2016-04-08 Thread wenzong.fan 
From: Wenzong Fan 

Apply the changes to refpolicy-minimum_2.20151208.bb:

  commit bfaf278116e6c3a04bb82c9f8a4f8629a0a85df8
  Author: Wenzong Fan 
  Date:   Tue Oct 27 06:25:04 2015 -0400

refpolicy-minimum: update prepare_policy_store

* update prepare_policy_store() for supporting SELinux 2.4 & CIL, the
  logic is from refpolicy_common.inc but with minimum set of policy
  modules;

* add extra policy modules that required by sysnetwork, without those
  modules the install process will fail with error:

| Failed to resolve roletype statement at 62 of \
  .../image/var/lib/selinux/minimum/tmp/modules/100/sysnetwork/cil
| Failed to resolve ast
| semodule:  Failed!

Signed-off-by: Wenzong Fan 
Signed-off-by: Joe MacDonald 

Signed-off-by: Wenzong Fan 
---
 .../refpolicy/refpolicy-minimum_2.20151208.bb  | 41 --
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb 
b/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb
index b275821..47ed558 100644
--- a/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb
+++ b/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb
@@ -26,23 +26,42 @@ EXTRA_POLICY_MODULES += "nscd"
 # "login", so "login" process will access to /var/spool/mail.
 EXTRA_POLICY_MODULES += "mta"
 
+# sysnetwork requires type definitions (insmod_t, consoletype_t,
+# hostname_t, ping_t, netutils_t) from modules:
+EXTRA_POLICY_MODULES += "modutils consoletype hostname netutils"
+
 POLICY_MODULES_MIN = "${CORE_POLICY_MODULES} ${EXTRA_POLICY_MODULES}"
 
 # re-write the same func from refpolicy_common.inc
 prepare_policy_store () {
oe_runmake 'DESTDIR=${D}' 'prefix=${D}${prefix}' install
+   POL_PRIORITY=100
+   POL_SRC=${D}${datadir}/selinux/${POLICY_NAME}
+   POL_STORE=${D}${localstatedir}/lib/selinux/${POLICY_NAME}
+   POL_ACTIVE_MODS=${POL_STORE}/active/modules/${POL_PRIORITY}
 
# Prepare to create policy store
-   mkdir -p ${D}${sysconfdir}/selinux/
-   mkdir -p ${D}${sysconfdir}/selinux/${POLICY_NAME}/policy
-   mkdir -p ${D}${sysconfdir}/selinux/${POLICY_NAME}/modules/active/modules
-   mkdir -p ${D}${sysconfdir}/selinux/${POLICY_NAME}/contexts/files
-   touch 
${D}${sysconfdir}/selinux/${POLICY_NAME}/contexts/files/file_contexts.local
-   for i in ${D}${datadir}/selinux/${POLICY_NAME}/*.pp; do
-   bzip2 -f $i && mv -f $i.bz2 $i
-   done
-   cp base.pp 
${D}${sysconfdir}/selinux/${POLICY_NAME}/modules/active/base.pp
-   for i in ${POLICY_MODULES_MIN}; do
-   cp ${i}.pp 
${D}${sysconfdir}/selinux/${POLICY_NAME}/modules/active/modules/`basename $i.pp`
+   mkdir -p ${POL_STORE}
+   mkdir -p ${POL_ACTIVE_MODS}
+
+   # get hll type from suffix on base policy module
+   HLL_TYPE=$(echo ${POL_SRC}/base.* | awk -F . '{if (NF>1) {print $NF}}')
+   HLL_BIN=${STAGING_DIR_NATIVE}${prefix}/libexec/selinux/hll/${HLL_TYPE}
+
+   for i in base ${POLICY_MODULES_MIN}; do
+   MOD_FILE=${POL_SRC}/${i}.${HLL_TYPE}
+   MOD_DIR=${POL_ACTIVE_MODS}/${i}
+   mkdir -p ${MOD_DIR}
+   echo -n "${HLL_TYPE}" > ${MOD_DIR}/lang_ext
+
+   if ! bzip2 -t ${MOD_FILE} >/dev/null 2>&1; then
+   ${HLL_BIN} ${MOD_FILE} | bzip2 --stdout > ${MOD_DIR}/cil
+   bzip2 -f ${MOD_FILE} && mv -f ${MOD_FILE}.bz2 
${MOD_FILE}
+   else
+   bunzip2 --stdout ${MOD_FILE} | \
+   ${HLL_BIN} | \
+   bzip2 --stdout > ${MOD_DIR}/cil
+   fi
+   cp ${MOD_FILE} ${MOD_DIR}/hll
done
 }
-- 
1.9.1

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

[linux-yocto] Feature branch on linux-yocto-3.14 for Valleyisland

2016-04-08 Thread chong . yi . chai 
From: "Chai, Chong Yi" 

Hi Bruce,

The feature branch (additional 66 commits) for enabling Valleyisland are ready 
to be fetched from Github.
This branch is targeted for kernel linux-yocto-3.14.

URL: https://github.com/yoctobsp/linux-yocto-3.14.git
Branch: standard/valleyisland


Stats:

Andy Shevchenko (9):
  dma: dw: allocate memory in two stages in probe
  dmaengine: dw: enable clock before access
  dmaengine: dw: fix regression in dw_probe() function
  dmaengine: dw: move dw_dmac.h to where it belongs to
  dmaengine: dw: convert dw_dma_slave to use explicit HS interfaces
  dmaengine: dw: apply both HS interfaces and remove slave_id usage
  dmaengine: dw: introduce generic filter function
  dmaengine: dw: move clock operations to platform.c
  serial: 8250: don't use slave_id of dma_slave_config

Antonio Ospite (1):
  spi/pxa2xx: fix runtime PM enabling order

Chew, Chiau Ee (5):
  x86/Kconfig: add PCI dependency for CONFIG_X86_INTEL_LPSS
  x86/byt: enable board file for BYT LPSS PCI mode
  dma: dw: Fix Intel MID DMA driver and Designware DMA driver loading
sequence
  spi/pxa2xx: change default supported DMA burst size to 1
  spi/pxa2xx: fix incorrect SW mode chipselect setting for BayTrail LPSS
SPI

Chew, Kean Ho (4):
  pinctrl-baytrail: unmap interrupt when free the gpio pin
  pinctrl-baytrail: enable platform device in the absent of ACPI
enumeration
  pinctrl-baytrail: setup IOAPIC interrupt for GPIO clusters on non-ACPI
system
  mmc: sdhci: Force BYT SDCARD host to run with SDR25 mode

Heikki Krogerus (2):
  serial: 8250_pci: remove rts_n override from Baytrail quirk
  ACPI / LPSS: not using UART RTS override with Auto Flow Control

Jingoo Han (1):
  spi: pxa2xx: remove unnecessary OOM messages

Loic Poulain (1):
  8250_dw: Support all baudrates on baytrail

Maurice Petallo (7):
  i2c: allow Designware I2C to be probed before SMBus for Baytrail
  mmc: sdhci: Preset value not supported in Baytrail eMMC
  mmc: sdhci: add DDR50 1.8V mode support for BayTrail eMMC Controller
  serial: 8250_pci: mask UART TX completion intr in byt_set_termios
  serial: 8250_dw: mask UART TX completion intr in byt_set_termios
  serial: 8250_core: handle_irq returns 1 only if data was processed
  thermal: Intel SoC DTS: Don't do thermal zone update inside spin_lock

Mika Westerberg (2):
  spi/pxa2xx: Prevent DMA from transferring too many bytes
  spi/pxa2xx: Don't use slave_id of dma_slave_config

Roger Quadros (1):
  usb: dwc3: core: Fix gadget for system suspend/resume

Sarah Sharp (1):
  usb/xhci: Change how we indicate a host supports Link PM.

Srinivas Pandruvada (1):
  thermal: Intel SoC DTS thermal

Wan Ahmad Zainie (31):
  dmaengine: dw: fix checkpatch.pl warnings
  pinctrl-baytrail: Serialize GPIO registers access with global spinlock
  hpet: refactor driver
  hpet: implement start/stop/query API
  hpet: Fix checkpatch.pl warnings
  i2c: designware: cleanup irq handler setting
  i2c: designware: use hardware-provided Rx/Tx FIFO depths
  i2c: designware: use symbolic names for command bits
  i2c: designware: cleanup __i2c_dw_enable()
  i2c: designware: explicitly abort running operation on disable
  i2c: designware: improve FIFO performance
  i2c: designware: add per-channel speed parameter and fast-plus speed
option
  i2c: designware: add i2c high-speed support
  i2c: designware: Fix checkpatch.pl warnings
  mmc: block: refactor read-only handling
  mmc: block: implement write request blocking
  mmc: support whole-device temporary write protection over CSD bits
13:12
  mmc: block: Fix checkpatch.pl warning
  pwm: Add freq_hz and duty_percent
  libata: add curr_xfer_mode attribute
  libata: enable atapi_an by default
  libata: handle HDIO_SET_DMA & HDIO_GET_DMA ioctl
  scsi: add extended information to MEDIA_CHANGE
  serial: 8250: Override the DCD and DSR pin status for Bay Trail
  spi/pxa2xx: auto switch between PIO and DMA with configurable
threshold size
  spi: modify spidev_test to test automatic PIO/DMA switching
  spi/pxa2xx: Add new ioctl for configuring FIFO trigger level in
runtime
  spi: modify spidev_test to test modifying FIFO trigger level during
runtime
  usb: core: hub: Generate uevent for overcurrent event
  usb: core: hub: Fix checkpatch.pl error
  watchdog: iTCO_wdt: Fix checkpatch.pl warnings

 Documentation/spi/spidev_test.c |  74 ++-
 MAINTAINERS |   2 +-
 arch/avr32/mach-at32ap/at32ap700x.c |  17 +-
 arch/avr32/mach-at32ap/include/mach/atmel-mci.h |   2 +-
 arch/x86/Kconfig|   9 +-
 arch/x86/platform/Makefile  |   3 +
 arch/x86/platform/byt/Makefile  |   1 +
 arch/x86/platform/byt/byt-board.c   |  84 
 drivers/acpi/acpi_lpss.c|  24 +-
 drivers/ata/libata-core.c   |   4 +-
 drivers/ata/libata-scsi.c   |  34 ++

[yocto] [PATCH] dev-manual: set correct task name for do_kernel_configme

2016-04-08 Thread Yi Zhao 
Signed-off-by: Yi Zhao 
---
 documentation/dev-manual/dev-manual-common-tasks.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml 
b/documentation/dev-manual/dev-manual-common-tasks.xml
index dc6ed46..d1c090b 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -5089,7 +5089,7 @@
 This configuration file will be your baseline.
 
 Separately run the
-do_configme and
+do_kernel_configme and
 do_kernel_configcheck tasks.
 
 Take the resulting list of files from the
@@ -5117,7 +5117,7 @@
 
 After you have worked through the output of the kernel
 configuration audit, you can re-run the
-do_configme and
+do_kernel_configme and
 do_kernel_configcheck tasks to
 see the results of your changes.
 If you have more issues, you can deal with them as
-- 
1.9.1

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