date:20160525

Re: [yocto] [meta-security][PATCH] Use bb.utils.contains instead of base_contains because it is deprecated

2016-05-25 Thread akuster



On 05/25/2016 01:24 AM, Thomas Perrot wrote:
> Signed-off-by: Thomas Perrot 
> ---
>  recipes-kernel/linux/linux-yocto_4.1.bbappend | 8 

merged.

>  recipes-security/clamav/clamav_0.99.1.bb  | 2 +-
>  recipes-security/sssd/sssd_1.13.3.bb  | 2 +-
>  recipes-tpm/trousers/trousers_0.3.13.bb   | 4 ++--

these last three are fixed in master-next. I just merged over master-next.

Thanks,

- armin
>  4 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/recipes-kernel/linux/linux-yocto_4.1.bbappend 
> b/recipes-kernel/linux/linux-yocto_4.1.bbappend
> index 1043d5c..dc90e31 100644
> --- a/recipes-kernel/linux/linux-yocto_4.1.bbappend
> +++ b/recipes-kernel/linux/linux-yocto_4.1.bbappend
> @@ -2,8 +2,8 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-4.1:"
>  
>  # Tomoyo kernel support
>  SRC_URI += "\
> - ${@base_contains('DISTRO_FEATURES', 'tomoyo', ' 
> file://ccs-tools-yocto.4.1.patch', '', d)} \
> - ${@base_contains('DISTRO_FEATURES', 'tomoyo', ' 
> file://ccs-tools-yocto_security.patch', '', d)} \
> - ${@base_contains('DISTRO_FEATURES', 'tomoyo', ' file://tomoyo.cfg', '', 
> d)} \
> - ${@base_contains('DISTRO_FEATURES', 'tomoyo', ' file://tomoyo.scc', '', 
> d)} \
> + ${@bb.utils.contains('DISTRO_FEATURES', 'tomoyo', ' 
> file://ccs-tools-yocto.4.1.patch', '', d)} \
> + ${@bb.utils.contains('DISTRO_FEATURES', 'tomoyo', ' 
> file://ccs-tools-yocto_security.patch', '', d)} \
> + ${@bb.utils.contains('DISTRO_FEATURES', 'tomoyo', ' file://tomoyo.cfg', 
> '', d)} \
> + ${@bb.utils.contains('DISTRO_FEATURES', 'tomoyo', ' file://tomoyo.scc', 
> '', d)} \
>   "
> diff --git a/recipes-security/clamav/clamav_0.99.1.bb 
> b/recipes-security/clamav/clamav_0.99.1.bb
> index edccc78..461015f 100644
> --- a/recipes-security/clamav/clamav_0.99.1.bb
> +++ b/recipes-security/clamav/clamav_0.99.1.bb
> @@ -30,7 +30,7 @@ GID = "clamav"
>  
>  PACKAGECONFIG ?= "ncurses openssl bz2 zlib "
>  PACKAGECONFIG += " ${@bb.utils.contains("DISTRO_FEATURES", "ipv6", "ipv6", 
> "", d)}"
> -PACKAGECONFIG += "${@base_contains('DISTRO_FEATURES', 'systemd', 'systemd', 
> '', d)}"
> +PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
> 'systemd', '', d)}"
>  PACKAGECONFIG[pcre] = "--with-pcre=${STAGING_LIBDIR},  --without-pcre, 
> libpcre"
>  PACKAGECONFIG[xml] = "--with-xml=${STAGING_LIBDIR}/.., --with-xml=no, 
> libxml2,"
>  PACKAGECONFIG[json] = "--with-libjson=${STAGING_LIBDIR}, --without-libjson, 
> json,"
> diff --git a/recipes-security/sssd/sssd_1.13.3.bb 
> b/recipes-security/sssd/sssd_1.13.3.bb
> index d538af3..fd4f2a2 100644
> --- a/recipes-security/sssd/sssd_1.13.3.bb
> +++ b/recipes-security/sssd/sssd_1.13.3.bb
> @@ -24,7 +24,7 @@ CACHED_CONFIGUREVARS = 
> "ac_cv_member_struct_ldap_conncb_lc_arg=no \
>  "
>  
>  PACKAGECONFIG ?="nss"
> -PACKAGECONFIG += "${@base_contains('DISTRO_FEATURES', 'selinux', 'selinux', 
> '', d)}"
> +PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 
> 'selinux', '', d)}"
>  
>  PACKAGECONFIG[ssh] = "--with-ssh, --with-ssh=no, "
>  PACKAGECONFIG[samba] = "--with-samba, --with-samba=no, samba"
> diff --git a/recipes-tpm/trousers/trousers_0.3.13.bb 
> b/recipes-tpm/trousers/trousers_0.3.13.bb
> index 7001788..e274972 100644
> --- a/recipes-tpm/trousers/trousers_0.3.13.bb
> +++ b/recipes-tpm/trousers/trousers_0.3.13.bb
> @@ -17,7 +17,7 @@ SRC_URI[md5sum] = "ad508f97b406f6e48cd90e85d78e7ca8"
>  SRC_URI[sha256sum] = 
> "bb908e4a3c88a17b247a4fc8e0fff3419d8a13170fe7bdfbe0e2c5c082a276d3"
>  
>  inherit autotools pkgconfig useradd update-rc.d
> -inherit 
> ${@base_contains('VIRTUAL-RUNTIME_init_manager','systemd','systemd','', d)}
> +inherit 
> ${@bb.utils.contains('VIRTUAL-RUNTIME_init_manager','systemd','systemd','', 
> d)}
>  
>  PACKAGECONFIG ?= "gmp "
>  PACKAGECONFIG[gmp] = "--with-gmp, --with-gmp=no, gmp"
> @@ -33,7 +33,7 @@ do_install_append() {
>  install -d ${D}${sysconfdir}/udev/rules.d
>  install -m 0644 ${WORKDIR}/trousers-udev.rules 
> ${D}${sysconfdir}/udev/rules.d/45-trousers.rules
>  
> -if ${@base_contains('DISTRO_FEATURES','systemd','true','false',d)}; then
> +if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
> then
>  install -d ${D}${systemd_unitdir}/system
>  install -m 0644 ${WORKDIR}/tcsd.service 
> ${D}${systemd_unitdir}/system/
>  sed -i -e 's#@SBINDIR@#${sbindir}#g' 
> ${D}${systemd_unitdir}/system/tcsd.service
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PULL REQUEST] Broxton related backports for linux-yocto-4.4

2016-05-25 Thread Bruce Ashfield


On 2016-05-25 5:27 PM, Saul Wold wrote:

On Wed, 2016-05-25 at 12:17 -0400, Bruce Ashfield wrote:

On 2016-05-24 4:19 PM, California Sullivan wrote:


Hi Bruce,

This is a set of backports from upstream. I have tested
allyesconfig,
allnoconfig, and standard builds and can't find anything wrong
there.
I have also tested running the kernel on MinnowBoard Max and there
are
no new errors or warnings.

Let me know if I need to make any modifications and send out a V2.

No need for a v2. They look fine to me, and I've staged them on
the kernel repo and have adjusted the SRCREVs. I'll send out the
update in a day or so.



Did you actually push them to the linux-yocto-4.4 repo yet?  Or are
they staged on your machine?


Just staged while I launched some builds.

Bruce



Sau!


Bruce




Thanks,
Cal Sullivan


he following changes since commit
628bf627561c6285d99fb978e11d4c15fc29324b:

  Merge tag 'v4.4.11' into standard/base (2016-05-19 09:02:42
-0400)

are available in the git repository at:

  git://git.yoctoproject.org/linux-yocto-contrib
clsulliv/standard/base

for you to fetch changes up to
53e84104c5e68eb468823dd0d262a64623d01a55:

  mmc: mmc: Fix partition switch timeout for some eMMCs (2016-05-19
17:15:25 -0700)


Adrian Hunter (3):
  mmc: sdhci: Remove SDHCI_SDR104_NEEDS_TUNING
  mmc: mmc: Attempt to flush cache before reset
  mmc: mmc: Fix partition switch timeout for some eMMCs

Andy Shevchenko (12):
  device property: always check for fwnode type
  device property: rename helper functions
  device property: refactor built-in properties support
  device property: keep single value inplace
  device property: improve readability of macros
  device property: return -EINVAL when property isn't found in
ACPI
  device property: Fallback to secondary fwnode if primary
misses the property
  mfd: core: propagate device properties to sub devices drivers
  mfd: intel-lpss: Pass HSUART configuration via properties
  device property: avoid allocations of 0 length
  lib/string: introduce match_string() helper
  device property: convert to use match_string() helper

Bamvor Jian Zhang (1):
  gpiolib: do not allow to insert an empty gpiochip

Christophe RICARD (2):
  ACPI: Rename acpi_gsi_get_irq_type to acpi_dev_get_irq_type
and export symbol
  ACPI / gpio: Add irq_type when a GPIO is used as an interrupt

Dasaratharaman Chandramouli (1):
  intel_idle: Support for Intel Xeon Phi Processor x200 Product
Family

Gwendal Grignou (1):
  mmc: core: Do regular power cycle when lacking eMMC HW reset
support

Heikki Krogerus (4):
  device property: helper macros for property entry creation
  device property: the secondary fwnode needs to depend on the
primary
  device property: fwnode->secondary may contain ERR_PTR(-
ENODEV)
  device property: fix for a case of use-after-free

Len Brown (2):
  intel_idle: Add SKX support
  intel_idle: add BXT support

Linus Walleij (1):
  Revert "gpio: revert get() to non-errorprogating behaviour"

Mika Westerberg (7):
  pwm: lpss: Remove ->free() callback
  pwm: lpss: Rework the sequence of programming PWM_SW_UPDATE
  device property: Take a copy of the property set
  driver core: platform: Add support for built-in device
properties
  mfd: intel-lpss: Add support for passing device properties
  mfd: intel-lpss: Pass SDA hold time to I2C host controller
driver
  mfd: intel-lpss: Pass I2C configuration via properties on BXT

Qipeng Zha (1):
  pinctrl: intel: make the high level interrupt working

Richard Cochran (10):
  intel_idle: remove useless return from void function.
  intel_idle: Fix a helper function's return value.
  intel_idle: Remove redundant initialization calls.
  intel_idle: Fix deallocation order on the driver exit path.
  intel_idle: Fix dangling registration on error path.
  intel_idle: Avoid a double free of the per-CPU data.
  intel_idle: Setup the timer broadcast only on successful
driver load.
  intel_idle: Don't overreact to a cpuidle registration
failure.
  intel_idle: Propagate hot plug errors.
  intel_idle: Clean up all registered devices on exit.

Wolfram Sang (1):
  mmc: make MAN_BKOPS_EN message a debug

qipeng.zha (1):
  pwm: lpss: Update PWM setting for Broxton

 arch/x86/include/asm/msr-index.h  |   8 +
 drivers/acpi/gsi.c|  21 +-
 drivers/acpi/property.c   |  10 +-
 drivers/acpi/resource.c   |  26 ++
 drivers/base/platform.c   |  25 ++
 drivers/base/property.c   | 516
+++---
 drivers/gpio/gpiolib-acpi.c   |  33 ++-
 drivers/gpio/gpiolib.c|  17 +-
 drivers/gpio/gpiolib.h|   3 +-
 drivers/idle/intel_idle.c | 257 +++--
 drivers/mfd/intel-lpss-acpi.c

Re: [yocto] [yocto-autobuilder][PATCH] GetLayerVersion.py: set new layer version only if cmd was sucessful and not already set

2016-05-25 Thread Randle, William C

On Wed, 2016-05-25 at 14:03 -0700, Randy Witt wrote:
> On 05/25/2016 01:28 PM, Bill Randle wrote:
> > 
> > Fixed a bug where GetLayerVersion set the layerversion to -1 when a
> > meta-poky layer.conf was not found.
> > 
> > Signed-off-by: Bill Randle 
> > ---
> >  .../autobuilder/buildsteps/GetLayerVersion.py | 15 ++
> > -
> >  1 file changed, 6 insertions(+), 9 deletions(-)
> > 
> > diff --git a/lib/python2.7/site-
> > packages/autobuilder/buildsteps/GetLayerVersion.py b/lib/python2.7/site-
> > packages/autobuilder/buildsteps/GetLayerVersion.py
> > index de5c203..3f167e8 100644
> > --- a/lib/python2.7/site-packages/autobuilder/buildsteps/GetLayerVersion.py
> > +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/GetLayerVersion.py
> > @@ -44,15 +44,12 @@ class GetLayerVersion(ShellCommand):
> >  ShellCommand.start(self)
> > 
> >  def commandComplete(self, cmd):
> > -result = cmd.logs['stdio'].getText()
> > -layerv= result.replace("LAYERVERSION_" + self.layerfile,
> > "").replace("=","").replace(' ','').replace('"','').replace("'",'').strip()
> > -if cmd.didFail():
> > -   layerv = "-1"
> > -if self.getProperty('layerversion_' + self.layerfile):
> > -self.finished(SUCCESS)
> > -else:
> > -self.setProperty('layerversion_' + self.layerfile, layerv,
> > "Setting Layer Version")
> > -self.finished(SUCCESS)
> > +if not cmd.didFail():
> > +result = cmd.logs['stdio'].getText()
> > +layerv = result.replace("LAYERVERSION_" + self.layerfile,
> > "").replace("=","").replace(' ','').replace('"','').replace("'",'').strip()
> > +if not self.getProperty('layerversion_' + self.layerfile):
> > +self.setProperty('layerversion_' + self.layerfile, layerv,
> > "Setting Layer Version")
> > +self.finished(SUCCESS)
> What happens if the command actually failed?

It just sets SUCCESS and carries on. What's going on is that the code that calls
this is iterating over different layers, starting with meta-poky, then meta-
yocto. When building a version prior to the meta-yocto -> meta-poky transition,
it will fail to find meta-poky/conf/layer.conf, but it's ok, because it will
next try meta-yocto/conf/layer.conf and succeed.

What was going on before is that on failure, if the layerversion was not
previouisly set, it would get set to -1 on that failure and not get overriden by
the correct version in meta-yocto/conf.

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

Re: [yocto] [yocto-autobuilder][PATCH] GetLayerVersion.py: set new layer version only if cmd was sucessful and not already set

2016-05-25 Thread Randy Witt


On 05/25/2016 01:28 PM, Bill Randle wrote:

Fixed a bug where GetLayerVersion set the layerversion to -1 when a
meta-poky layer.conf was not found.

Signed-off-by: Bill Randle 
---
 .../autobuilder/buildsteps/GetLayerVersion.py | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/GetLayerVersion.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/GetLayerVersion.py
index de5c203..3f167e8 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/GetLayerVersion.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/GetLayerVersion.py
@@ -44,15 +44,12 @@ class GetLayerVersion(ShellCommand):
 ShellCommand.start(self)

 def commandComplete(self, cmd):
-result = cmd.logs['stdio'].getText()
-layerv= result.replace("LAYERVERSION_" + self.layerfile, 
"").replace("=","").replace(' ','').replace('"','').replace("'",'').strip()
-if cmd.didFail():
-   layerv = "-1"
-if self.getProperty('layerversion_' + self.layerfile):
-self.finished(SUCCESS)
-else:
-self.setProperty('layerversion_' + self.layerfile, layerv, "Setting 
Layer Version")
-self.finished(SUCCESS)
+if not cmd.didFail():
+result = cmd.logs['stdio'].getText()
+layerv = result.replace("LAYERVERSION_" + self.layerfile, 
"").replace("=","").replace(' ','').replace('"','').replace("'",'').strip()
+if not self.getProperty('layerversion_' + self.layerfile):
+self.setProperty('layerversion_' + self.layerfile, layerv, "Setting 
Layer Version")
+self.finished(SUCCESS)


What happens if the command actually failed?


 def getText(self, cmd, results):
 return ShellCommand.getText(self, cmd, results)



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

[yocto] [yocto-autobuilder][PATCH] GetLayerVersion.py: set new layer version only if cmd was sucessful and not already set

2016-05-25 Thread Bill Randle

Fixed a bug where GetLayerVersion set the layerversion to -1 when a
meta-poky layer.conf was not found.

Signed-off-by: Bill Randle 
---
 .../autobuilder/buildsteps/GetLayerVersion.py | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/GetLayerVersion.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/GetLayerVersion.py
index de5c203..3f167e8 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/GetLayerVersion.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/GetLayerVersion.py
@@ -44,15 +44,12 @@ class GetLayerVersion(ShellCommand):
 ShellCommand.start(self)
 
 def commandComplete(self, cmd):
-result = cmd.logs['stdio'].getText()
-layerv= result.replace("LAYERVERSION_" + self.layerfile, 
"").replace("=","").replace(' ','').replace('"','').replace("'",'').strip()
-if cmd.didFail():
-   layerv = "-1"
-if self.getProperty('layerversion_' + self.layerfile):
-self.finished(SUCCESS)
-else:
-self.setProperty('layerversion_' + self.layerfile, layerv, 
"Setting Layer Version")
-self.finished(SUCCESS)
+if not cmd.didFail():
+result = cmd.logs['stdio'].getText()
+layerv = result.replace("LAYERVERSION_" + self.layerfile, 
"").replace("=","").replace(' ','').replace('"','').replace("'",'').strip()
+if not self.getProperty('layerversion_' + self.layerfile):
+self.setProperty('layerversion_' + self.layerfile, layerv, 
"Setting Layer Version")
+self.finished(SUCCESS)
 
 def getText(self, cmd, results):
 return ShellCommand.getText(self, cmd, results)
-- 
2.5.5

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

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

2016-05-25 Thread Rudolf J Streif

> 
>   hmm ... the client requirements are only that it use u-boot,
> with the mender software integrated into u-boot. so if one can
> configure and build that for powerpc, then install and boot u-boot on
> the target board, why should it then be restricted to ARM?
>
>   sure, their reference board is a BBB, but a quick glance at the docs
> doesn't seem to say that it works *only* on ARM. must look closer ...
>
Correct. However, it currently assumes the specific BeagleB* partition layout 
for the SSD card. But that I would think could be adjusted for other other 
devices. They apparently also made some modifications to u-boot itself. I don't 
know what exactly those are though.
 
:rjs
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

2016-05-25 Thread Robert P. J. Day

On Wed, 25 May 2016, Rudolf J Streif wrote:

>
> Hi Robert,
>
>  
>
> On Wednesday, May 25, 2016 06:18:34 AM Robert P. J. Day wrote:
>
> >
>
> > specifically in the context of powerpc systems, are there any
>
> > suggestions for an image that could be used to boot an older powerpc
>
> > system, running completely out of ram, and using that as an install
>
> > utility which would then be responsible for detecting/formatting a
>
> > hard drive, creating/formatting filesystems, downloading/installing
>
> > the OS, post-install configuration and so on?
>
> I am not entirely sure if I understand your requirements correctly
> but this https://github.com/mendersoftware/mender could eventually
> be a starting point. The good news is that it already comes with
> YP/OE recipes and integration. However, it's currently only for
> ARM-based systems with u-boot.

  hmm ... the client requirements are only that it use u-boot,
with the mender software integrated into u-boot. so if one can
configure and build that for powerpc, then install and boot u-boot on
the target board, why should it then be restricted to ARM?

  sure, their reference board is a BBB, but a quick glance at the docs
doesn't seem to say that it works *only* on ARM. must look closer ...

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] any pointers to a yocto-based image to use as a live install utility?

2016-05-25 Thread Rudolf J Streif

Hi Robert,

On Wednesday, May 25, 2016 06:18:34 AM Robert P. J. Day wrote:
> 
>   specifically in the context of powerpc systems, are there any
> suggestions for an image that could be used to boot an older powerpc
> system, running completely out of ram, and using that as an install
> utility which would then be responsible for detecting/formatting a
> hard drive, creating/formatting filesystems, downloading/installing
> the OS, post-install configuration and so on?
> 
I am not entirely sure if I understand your requirements correctly but this 
https://github.com/mendersoftware/mender[1] could eventually be a starting 
point. The good news is that it already comes with YP/OE recipes and 
integration. However, it's currently only for ARM-based systems with u-boot.

Another approach, though still in its infancy and a simple PoC, is the GENIVI 
Software Management (SWM). At the core, there are SqashFS images that may 
contain partition images, software packages, configuration files, etc. together 
with a manifest (JSON) that instructs the SWM what to do. 
(https://github.com/GENIVI/genivi_swm)[2]

Cheers,
:rjs



[1] https://github.com/mendersoftware/mender
[2] https://github.com/GENIVI/genivi_swm
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PULL REQUEST] Broxton related backports for linux-yocto-4.4

2016-05-25 Thread Bruce Ashfield


On 2016-05-24 4:19 PM, California Sullivan wrote:

Hi Bruce,

This is a set of backports from upstream. I have tested allyesconfig,
allnoconfig, and standard builds and can't find anything wrong there.
I have also tested running the kernel on MinnowBoard Max and there are
no new errors or warnings.

Let me know if I need to make any modifications and send out a V2.


No need for a v2. They look fine to me, and I've staged them on
the kernel repo and have adjusted the SRCREVs. I'll send out the
update in a day or so.

Bruce



Thanks,
Cal Sullivan


he following changes since commit 628bf627561c6285d99fb978e11d4c15fc29324b:

  Merge tag 'v4.4.11' into standard/base (2016-05-19 09:02:42 -0400)

are available in the git repository at:

  git://git.yoctoproject.org/linux-yocto-contrib clsulliv/standard/base

for you to fetch changes up to 53e84104c5e68eb468823dd0d262a64623d01a55:

  mmc: mmc: Fix partition switch timeout for some eMMCs (2016-05-19 17:15:25 
-0700)


Adrian Hunter (3):
  mmc: sdhci: Remove SDHCI_SDR104_NEEDS_TUNING
  mmc: mmc: Attempt to flush cache before reset
  mmc: mmc: Fix partition switch timeout for some eMMCs

Andy Shevchenko (12):
  device property: always check for fwnode type
  device property: rename helper functions
  device property: refactor built-in properties support
  device property: keep single value inplace
  device property: improve readability of macros
  device property: return -EINVAL when property isn't found in ACPI
  device property: Fallback to secondary fwnode if primary misses the 
property
  mfd: core: propagate device properties to sub devices drivers
  mfd: intel-lpss: Pass HSUART configuration via properties
  device property: avoid allocations of 0 length
  lib/string: introduce match_string() helper
  device property: convert to use match_string() helper

Bamvor Jian Zhang (1):
  gpiolib: do not allow to insert an empty gpiochip

Christophe RICARD (2):
  ACPI: Rename acpi_gsi_get_irq_type to acpi_dev_get_irq_type and export 
symbol
  ACPI / gpio: Add irq_type when a GPIO is used as an interrupt

Dasaratharaman Chandramouli (1):
  intel_idle: Support for Intel Xeon Phi Processor x200 Product Family

Gwendal Grignou (1):
  mmc: core: Do regular power cycle when lacking eMMC HW reset support

Heikki Krogerus (4):
  device property: helper macros for property entry creation
  device property: the secondary fwnode needs to depend on the primary
  device property: fwnode->secondary may contain ERR_PTR(-ENODEV)
  device property: fix for a case of use-after-free

Len Brown (2):
  intel_idle: Add SKX support
  intel_idle: add BXT support

Linus Walleij (1):
  Revert "gpio: revert get() to non-errorprogating behaviour"

Mika Westerberg (7):
  pwm: lpss: Remove ->free() callback
  pwm: lpss: Rework the sequence of programming PWM_SW_UPDATE
  device property: Take a copy of the property set
  driver core: platform: Add support for built-in device properties
  mfd: intel-lpss: Add support for passing device properties
  mfd: intel-lpss: Pass SDA hold time to I2C host controller driver
  mfd: intel-lpss: Pass I2C configuration via properties on BXT

Qipeng Zha (1):
  pinctrl: intel: make the high level interrupt working

Richard Cochran (10):
  intel_idle: remove useless return from void function.
  intel_idle: Fix a helper function's return value.
  intel_idle: Remove redundant initialization calls.
  intel_idle: Fix deallocation order on the driver exit path.
  intel_idle: Fix dangling registration on error path.
  intel_idle: Avoid a double free of the per-CPU data.
  intel_idle: Setup the timer broadcast only on successful driver load.
  intel_idle: Don't overreact to a cpuidle registration failure.
  intel_idle: Propagate hot plug errors.
  intel_idle: Clean up all registered devices on exit.

Wolfram Sang (1):
  mmc: make MAN_BKOPS_EN message a debug

qipeng.zha (1):
  pwm: lpss: Update PWM setting for Broxton

 arch/x86/include/asm/msr-index.h  |   8 +
 drivers/acpi/gsi.c|  21 +-
 drivers/acpi/property.c   |  10 +-
 drivers/acpi/resource.c   |  26 ++
 drivers/base/platform.c   |  25 ++
 drivers/base/property.c   | 516 +++---
 drivers/gpio/gpiolib-acpi.c   |  33 ++-
 drivers/gpio/gpiolib.c|  17 +-
 drivers/gpio/gpiolib.h|   3 +-
 drivers/idle/intel_idle.c | 257 +++--
 drivers/mfd/intel-lpss-acpi.c |  31 +-
 drivers/mfd/intel-lpss-pci.c  |  56 +++-
 drivers/mfd/intel-lpss.c  |  16 +-
 drivers/mfd/intel-lpss.h  |   2 +
 drivers/mfd/mfd-core.c|   7 +
 drivers/mmc/core/core.c   |   5 +-

Re: [yocto] mount bind /var/lib and package management

2016-05-25 Thread Fred Ollinger

Bind mount can allow mount to be two places:

>From the mount manpage:

"   The bind mounts.
  Since Linux 2.4.0 it is possible to remount part of the file 
hierarchy somewhere else.  The call is:

 mount --bind olddir newdir"

If you do this, then you have your files on tmpfs.

Frederick

From: yocto-boun...@yoctoproject.org  on behalf 
of Martin Townsend 
Sent: Wednesday, May 25, 2016 8:07 AM
To: yocto@yoctoproject.org
Subject: [yocto] mount bind /var/lib and package management

Hi,

When using a read only rootfs it mount --binds /var/lib into
/var/volatile/lib which lives in tmpfs and makes sense.  The problem
is that I use dpkg but I'm assuming other package management tools use
/var/lib as their admin dir.

Wouldn't this break package updates as the dpkg database files etc
will then be updated in tmpfs so a power cycle would means the changes
are lost? Or am I missing something?

I tried to mount bind all directories except dpkg which I managed to
get working but other systemd services failed as they expected
/var/lib to be writeable (the service that creates /var/lib/machines).
I suppose I could alter this to remount / rw first but gave up at this
point.

The next thing I tried was to use a new admindir for dpkg, ie
/lib/dpkg which I have working but I had to hack a lot of files
changing /var/lib to /lib including files for apt-get native.  I'm not
confident that I've got them all.

Is there another solution I haven't thought of?

Thanks in advance,
Martin.
--
___
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] any pointers to a yocto-based image to use as a live install utility?

2016-05-25 Thread Robert P. J. Day

On Wed, 25 May 2016, Bruce Ashfield wrote:

> On 2016-05-25 11:26 AM, Robert P. J. Day wrote:
> > On Wed, 25 May 2016, Bruce Ashfield wrote:
> >
> > > On 2016-05-25 11:00 AM, akuster wrote:
> > > > Robert,
> > > >
> > > >
> > > > On 05/25/2016 03:18 AM, Robert P. J. Day wrote:
> > > > >
> > > > >   specifically in the context of powerpc systems, are there
> > > > > any suggestions for an image that could be used to boot an
> > > > > older powerpc system, running completely out of ram, and
> > > > > using that as an install utility which would then be
> > > > > responsible for detecting/formatting a hard drive,
> > > > > creating/formatting filesystems, downloading/installing the
> > > > > OS, post-install configuration and so on?
> > > >
> > > > This sounds like an installer MV has and that I have been
> > > > given approval to release (just haven’t had the time to submit
> > > > it). Its X86 centric ie uses grub and support efi
> > > >
> > > > It boots up from an iso image and runs a ncurses based
> > > > interface that allows you to select HD, create partitions and
> > > > filesystem types. It will install what ever image you built.
> > > > It creates grub conf and installs it. The installer bit is
> > > > written in python.
> > >
> > > If you do end up releasing it, I have some "installer tech" that
> > > runs on non-x86 that I can see how it fits together.
> >
> >   if any of that "installer tech" is relevant for powerpc, that
> > would be most excellent. would that be related to WRL's "Installer
> > Image"?
>
> In this case no. It is something simpler for a container OS, but it
> does run from a bootable USB and has a simple backend that you can
> customize for a given platform. The only trick is getting the right
> bootable USB for non-x86.

  oh, darn ... i haz a sad. so it looks like i'm pretty well starting
from scratch, unless someone has pointers to anything i can use or
cannibalize to use as a starting point.

  basically, i'm after something that:

  * runs on powerpc
  * has the ability to scan the hard drive and decide what to do
about existing partitions, possibly preserving them
  * runs entirely standalone as it must be run on remote systems

the plan right now is to create a live linux image, and having to
pretty much manually do the above, so if you have any shortcuts, i'm
all ears.

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] any pointers to a yocto-based image to use as a live install utility?

2016-05-25 Thread Robert P. J. Day

On Wed, 25 May 2016, Bruce Ashfield wrote:

> On 2016-05-25 11:00 AM, akuster wrote:
> > Robert,
> >
> >
> > On 05/25/2016 03:18 AM, Robert P. J. Day wrote:
> > >
> > >   specifically in the context of powerpc systems, are there any
> > > suggestions for an image that could be used to boot an older
> > > powerpc system, running completely out of ram, and using that as
> > > an install utility which would then be responsible for
> > > detecting/formatting a hard drive, creating/formatting
> > > filesystems, downloading/installing the OS, post-install
> > > configuration and so on?
> >
> > This sounds like an installer MV has and that I have been given
> > approval to release (just haven’t had the time to submit it).
> > Its X86 centric ie uses grub and support efi
> >
> > It boots up from an iso image and runs a ncurses based interface
> > that allows you to select HD, create partitions and filesystem
> > types. It will install what ever image you built. It creates grub
> > conf and installs it. The installer bit is written in python.
>
> If you do end up releasing it, I have some "installer tech" that
> runs on non-x86 that I can see how it fits together.

  just to be clear, we're using WRL 8, and i found the docs related to
WRL's "Installer Image" a while back, but it's based on kickstart so
it seems pretty well exclusive to x86.

  if there's something equivalent that works for powerpc, i would be a
thoroughly happy camper.

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] any pointers to a yocto-based image to use as a live install utility?

2016-05-25 Thread Bruce Ashfield


On 2016-05-25 11:26 AM, Robert P. J. Day wrote:

On Wed, 25 May 2016, Bruce Ashfield wrote:


On 2016-05-25 11:00 AM, akuster wrote:

Robert,


On 05/25/2016 03:18 AM, Robert P. J. Day wrote:


  specifically in the context of powerpc systems, are there any
suggestions for an image that could be used to boot an older
powerpc system, running completely out of ram, and using that as
an install utility which would then be responsible for
detecting/formatting a hard drive, creating/formatting
filesystems, downloading/installing the OS, post-install
configuration and so on?


This sounds like an installer MV has and that I have been given
approval to release (just haven’t had the time to submit it).
Its X86 centric ie uses grub and support efi

It boots up from an iso image and runs a ncurses based interface
that allows you to select HD, create partitions and filesystem
types. It will install what ever image you built. It creates grub
conf and installs it. The installer bit is written in python.


If you do end up releasing it, I have some "installer tech" that
runs on non-x86 that I can see how it fits together.


  if any of that "installer tech" is relevant for powerpc, that would
be most excellent. would that be related to WRL's "Installer Image"?


In this case no. It is something simpler for a container OS, but it
does run from a bootable USB and has a simple backend that you can
customize for a given platform. The only trick is getting the right
bootable USB for non-x86.

Bruce



rday



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

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

2016-05-25 Thread Robert P. J. Day

On Wed, 25 May 2016, Bruce Ashfield wrote:

> On 2016-05-25 11:00 AM, akuster wrote:
> > Robert,
> >
> >
> > On 05/25/2016 03:18 AM, Robert P. J. Day wrote:
> > >
> > >   specifically in the context of powerpc systems, are there any
> > > suggestions for an image that could be used to boot an older
> > > powerpc system, running completely out of ram, and using that as
> > > an install utility which would then be responsible for
> > > detecting/formatting a hard drive, creating/formatting
> > > filesystems, downloading/installing the OS, post-install
> > > configuration and so on?
> >
> > This sounds like an installer MV has and that I have been given
> > approval to release (just haven’t had the time to submit it).
> > Its X86 centric ie uses grub and support efi
> >
> > It boots up from an iso image and runs a ncurses based interface
> > that allows you to select HD, create partitions and filesystem
> > types. It will install what ever image you built. It creates grub
> > conf and installs it. The installer bit is written in python.
>
> If you do end up releasing it, I have some "installer tech" that
> runs on non-x86 that I can see how it fits together.

  if any of that "installer tech" is relevant for powerpc, that would
be most excellent. would that be related to WRL's "Installer Image"?

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] any pointers to a yocto-based image to use as a live install utility?

2016-05-25 Thread Bruce Ashfield


On 2016-05-25 11:00 AM, akuster wrote:

Robert,


On 05/25/2016 03:18 AM, Robert P. J. Day wrote:


  specifically in the context of powerpc systems, are there any
suggestions for an image that could be used to boot an older powerpc
system, running completely out of ram, and using that as an install
utility which would then be responsible for detecting/formatting a
hard drive, creating/formatting filesystems, downloading/installing
the OS, post-install configuration and so on?


This sounds like an installer MV has and that I have been given approval
to release (just haven’t had the time to submit it).  Its X86 centric ie
uses grub and support efi

It boots up from an iso image and runs a ncurses based interface that
allows you to select HD, create partitions and filesystem types. It will
install what ever image you built. It creates grub conf and installs it.
The installer bit is written in python.


If you do end up releasing it, I have some "installer tech" that runs
on non-x86 that I can see how it fits together.

Bruce





  i realize that's a spectacularly imprecise request -- in a general
sense, it involves just starting with a regular image, then adding
utilities that run around doing all of the above, but if there's
anything that already takes one most of the way there, that'd be
great.



Does this sound like something you are thing about?

regards,
Armin

  thoughts?

rday



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

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

2016-05-25 Thread Matt Broadstone

On Wed, May 25, 2016 at 11:03 AM, Robert P. J. Day 
wrote:

> On Wed, 25 May 2016, akuster wrote:
>
> > Robert,
> >
> > On 05/25/2016 03:18 AM, Robert P. J. Day wrote:
> > >
> > >   specifically in the context of powerpc systems, are there any
> > > suggestions for an image that could be used to boot an older powerpc
> > > system, running completely out of ram, and using that as an install
> > > utility which would then be responsible for detecting/formatting a
> > > hard drive, creating/formatting filesystems, downloading/installing
> > > the OS, post-install configuration and so on?
> >
> > This sounds like an installer MV has and that I have been given approval
> > to release (just haven’t had the time to submit it).  Its X86 centric ie
> > uses grub and support efi
> >
>

I'm incredibly interested in this, do you have a tentative release plan?

Regards,
Matt


> > It boots up from an iso image and runs a ncurses based interface that
> > allows you to select HD, create partitions and filesystem types. It will
> > install what ever image you built. It creates grub conf and installs it.
> > The installer bit is written in python.
>
>   given that it's based on grub, how compatible would it be with a
> powerpc target? what i need is *specifically* for powerpc. and what
> i'm after can't require a graphical interface, it needs to be
> script-based as it will have to run on remote systems.
>
> 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] any pointers to a yocto-based image to use as a live install utility?

2016-05-25 Thread Robert P. J. Day

On Wed, 25 May 2016, akuster wrote:

> Robert,
>
> On 05/25/2016 03:18 AM, Robert P. J. Day wrote:
> >
> >   specifically in the context of powerpc systems, are there any
> > suggestions for an image that could be used to boot an older powerpc
> > system, running completely out of ram, and using that as an install
> > utility which would then be responsible for detecting/formatting a
> > hard drive, creating/formatting filesystems, downloading/installing
> > the OS, post-install configuration and so on?
>
> This sounds like an installer MV has and that I have been given approval
> to release (just haven’t had the time to submit it).  Its X86 centric ie
> uses grub and support efi
>
> It boots up from an iso image and runs a ncurses based interface that
> allows you to select HD, create partitions and filesystem types. It will
> install what ever image you built. It creates grub conf and installs it.
> The installer bit is written in python.

  given that it's based on grub, how compatible would it be with a
powerpc target? what i need is *specifically* for powerpc. and what
i'm after can't require a graphical interface, it needs to be
script-based as it will have to run on remote systems.

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] any pointers to a yocto-based image to use as a live install utility?

2016-05-25 Thread akuster

Robert,

On 05/25/2016 03:18 AM, Robert P. J. Day wrote:
> 
>   specifically in the context of powerpc systems, are there any
> suggestions for an image that could be used to boot an older powerpc
> system, running completely out of ram, and using that as an install
> utility which would then be responsible for detecting/formatting a
> hard drive, creating/formatting filesystems, downloading/installing
> the OS, post-install configuration and so on?

This sounds like an installer MV has and that I have been given approval
to release (just haven’t had the time to submit it).  Its X86 centric ie
uses grub and support efi

It boots up from an iso image and runs a ncurses based interface that
allows you to select HD, create partitions and filesystem types. It will
install what ever image you built. It creates grub conf and installs it.
The installer bit is written in python.

> 
>   i realize that's a spectacularly imprecise request -- in a general
> sense, it involves just starting with a regular image, then adding
> utilities that run around doing all of the above, but if there's
> anything that already takes one most of the way there, that'd be
> great.
> 

Does this sound like something you are thing about?

regards,
Armin
>   thoughts?
> 
> rday
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-virtualization][PATCH] Use bb.utils.contains instead of base_contains because it is deprecated

2016-05-25 Thread Bruce Ashfield


On 2016-05-25 4:27 AM, Thomas Perrot wrote:

Signed-off-by: Thomas Perrot 


I already had a change queued here for this, that I managed to
forget to push.

I'll rebase and do that now.

Cheers,

Bruce


---
 recipes-containers/containerd/containerd_git.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-containers/containerd/containerd_git.bb 
b/recipes-containers/containerd/containerd_git.bb
index 46b9dc1..1a2c445 100644
--- a/recipes-containers/containerd/containerd_git.bb
+++ b/recipes-containers/containerd/containerd_git.bb
@@ -59,8 +59,8 @@ do_compile() {

 # Note: disabled for now, since docker is launching containerd
 # inherit systemd
-# SYSTEMD_PACKAGES = 
"${@base_contains('DISTRO_FEATURES','systemd','${PN}','',d)}"
-# SYSTEMD_SERVICE_${PN} = 
"${@base_contains('DISTRO_FEATURES','systemd','containerd.service','',d)}"
+# SYSTEMD_PACKAGES = 
"${@bb.utils.contains('DISTRO_FEATURES','systemd','${PN}','',d)}"
+# SYSTEMD_SERVICE_${PN} = 
"${@bb.utils.contains('DISTRO_FEATURES','systemd','containerd.service','',d)}"

 do_install() {
mkdir -p ${D}/${bindir}
@@ -73,7 +73,7 @@ do_install() {
ln -sf containerd-shim ${D}/${bindir}/docker-containerd-shim
ln -sf containerd-ctr ${D}/${bindir}/docker-containerd-ctr

-   if ${@base_contains('DISTRO_FEATURES','systemd','true','false',d)}; then
+   if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
then
install -d ${D}${systemd_unitdir}/system
install -m 644 ${S}/hack/containerd.service 
${D}/${systemd_unitdir}/system
# adjust from /usr/local/bin to /usr/bin/



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

[yocto] any pointers to a yocto-based image to use as a live install utility?

2016-05-25 Thread Robert P. J. Day


  specifically in the context of powerpc systems, are there any
suggestions for an image that could be used to boot an older powerpc
system, running completely out of ram, and using that as an install
utility which would then be responsible for detecting/formatting a
hard drive, creating/formatting filesystems, downloading/installing
the OS, post-install configuration and so on?

  i realize that's a spectacularly imprecise request -- in a general
sense, it involves just starting with a regular image, then adding
utilities that run around doing all of the above, but if there's
anything that already takes one most of the way there, that'd be
great.

  thoughts?

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] [meta-virtualization][PATCH] Use bb.utils.contains instead of base_contains because it is deprecated

2016-05-25 Thread Thomas Perrot

Signed-off-by: Thomas Perrot 
---
 recipes-containers/containerd/containerd_git.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-containers/containerd/containerd_git.bb 
b/recipes-containers/containerd/containerd_git.bb
index 46b9dc1..1a2c445 100644
--- a/recipes-containers/containerd/containerd_git.bb
+++ b/recipes-containers/containerd/containerd_git.bb
@@ -59,8 +59,8 @@ do_compile() {
 
 # Note: disabled for now, since docker is launching containerd
 # inherit systemd
-# SYSTEMD_PACKAGES = 
"${@base_contains('DISTRO_FEATURES','systemd','${PN}','',d)}"
-# SYSTEMD_SERVICE_${PN} = 
"${@base_contains('DISTRO_FEATURES','systemd','containerd.service','',d)}"
+# SYSTEMD_PACKAGES = 
"${@bb.utils.contains('DISTRO_FEATURES','systemd','${PN}','',d)}"
+# SYSTEMD_SERVICE_${PN} = 
"${@bb.utils.contains('DISTRO_FEATURES','systemd','containerd.service','',d)}"
 
 do_install() {
mkdir -p ${D}/${bindir}
@@ -73,7 +73,7 @@ do_install() {
ln -sf containerd-shim ${D}/${bindir}/docker-containerd-shim
ln -sf containerd-ctr ${D}/${bindir}/docker-containerd-ctr
 
-   if ${@base_contains('DISTRO_FEATURES','systemd','true','false',d)}; then
+   if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
then
install -d ${D}${systemd_unitdir}/system
install -m 644 ${S}/hack/containerd.service 
${D}/${systemd_unitdir}/system
# adjust from /usr/local/bin to /usr/bin/
-- 
2.1.4

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

[yocto] [meta-security][PATCH] Use bb.utils.contains instead of base_contains because it is deprecated

2016-05-25 Thread Thomas Perrot

Signed-off-by: Thomas Perrot 
---
 recipes-kernel/linux/linux-yocto_4.1.bbappend | 8 
 recipes-security/clamav/clamav_0.99.1.bb  | 2 +-
 recipes-security/sssd/sssd_1.13.3.bb  | 2 +-
 recipes-tpm/trousers/trousers_0.3.13.bb   | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/recipes-kernel/linux/linux-yocto_4.1.bbappend 
b/recipes-kernel/linux/linux-yocto_4.1.bbappend
index 1043d5c..dc90e31 100644
--- a/recipes-kernel/linux/linux-yocto_4.1.bbappend
+++ b/recipes-kernel/linux/linux-yocto_4.1.bbappend
@@ -2,8 +2,8 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-4.1:"
 
 # Tomoyo kernel support
 SRC_URI += "\
-   ${@base_contains('DISTRO_FEATURES', 'tomoyo', ' 
file://ccs-tools-yocto.4.1.patch', '', d)} \
-   ${@base_contains('DISTRO_FEATURES', 'tomoyo', ' 
file://ccs-tools-yocto_security.patch', '', d)} \
-   ${@base_contains('DISTRO_FEATURES', 'tomoyo', ' file://tomoyo.cfg', '', 
d)} \
-   ${@base_contains('DISTRO_FEATURES', 'tomoyo', ' file://tomoyo.scc', '', 
d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'tomoyo', ' 
file://ccs-tools-yocto.4.1.patch', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'tomoyo', ' 
file://ccs-tools-yocto_security.patch', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'tomoyo', ' file://tomoyo.cfg', 
'', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'tomoyo', ' file://tomoyo.scc', 
'', d)} \
"
diff --git a/recipes-security/clamav/clamav_0.99.1.bb 
b/recipes-security/clamav/clamav_0.99.1.bb
index edccc78..461015f 100644
--- a/recipes-security/clamav/clamav_0.99.1.bb
+++ b/recipes-security/clamav/clamav_0.99.1.bb
@@ -30,7 +30,7 @@ GID = "clamav"
 
 PACKAGECONFIG ?= "ncurses openssl bz2 zlib "
 PACKAGECONFIG += " ${@bb.utils.contains("DISTRO_FEATURES", "ipv6", "ipv6", "", 
d)}"
-PACKAGECONFIG += "${@base_contains('DISTRO_FEATURES', 'systemd', 'systemd', 
'', d)}"
+PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
'systemd', '', d)}"
 PACKAGECONFIG[pcre] = "--with-pcre=${STAGING_LIBDIR},  --without-pcre, libpcre"
 PACKAGECONFIG[xml] = "--with-xml=${STAGING_LIBDIR}/.., --with-xml=no, libxml2,"
 PACKAGECONFIG[json] = "--with-libjson=${STAGING_LIBDIR}, --without-libjson, 
json,"
diff --git a/recipes-security/sssd/sssd_1.13.3.bb 
b/recipes-security/sssd/sssd_1.13.3.bb
index d538af3..fd4f2a2 100644
--- a/recipes-security/sssd/sssd_1.13.3.bb
+++ b/recipes-security/sssd/sssd_1.13.3.bb
@@ -24,7 +24,7 @@ CACHED_CONFIGUREVARS = 
"ac_cv_member_struct_ldap_conncb_lc_arg=no \
 "
 
 PACKAGECONFIG ?="nss"
-PACKAGECONFIG += "${@base_contains('DISTRO_FEATURES', 'selinux', 'selinux', 
'', d)}"
+PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 
'selinux', '', d)}"
 
 PACKAGECONFIG[ssh] = "--with-ssh, --with-ssh=no, "
 PACKAGECONFIG[samba] = "--with-samba, --with-samba=no, samba"
diff --git a/recipes-tpm/trousers/trousers_0.3.13.bb 
b/recipes-tpm/trousers/trousers_0.3.13.bb
index 7001788..e274972 100644
--- a/recipes-tpm/trousers/trousers_0.3.13.bb
+++ b/recipes-tpm/trousers/trousers_0.3.13.bb
@@ -17,7 +17,7 @@ SRC_URI[md5sum] = "ad508f97b406f6e48cd90e85d78e7ca8"
 SRC_URI[sha256sum] = 
"bb908e4a3c88a17b247a4fc8e0fff3419d8a13170fe7bdfbe0e2c5c082a276d3"
 
 inherit autotools pkgconfig useradd update-rc.d
-inherit 
${@base_contains('VIRTUAL-RUNTIME_init_manager','systemd','systemd','', d)}
+inherit 
${@bb.utils.contains('VIRTUAL-RUNTIME_init_manager','systemd','systemd','', d)}
 
 PACKAGECONFIG ?= "gmp "
 PACKAGECONFIG[gmp] = "--with-gmp, --with-gmp=no, gmp"
@@ -33,7 +33,7 @@ do_install_append() {
 install -d ${D}${sysconfdir}/udev/rules.d
 install -m 0644 ${WORKDIR}/trousers-udev.rules 
${D}${sysconfdir}/udev/rules.d/45-trousers.rules
 
-if ${@base_contains('DISTRO_FEATURES','systemd','true','false',d)}; then
+if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
then
 install -d ${D}${systemd_unitdir}/system
 install -m 0644 ${WORKDIR}/tcsd.service ${D}${systemd_unitdir}/system/
 sed -i -e 's#@SBINDIR@#${sbindir}#g' 
${D}${systemd_unitdir}/system/tcsd.service
-- 
2.1.4

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

Re: [yocto] [psplash][PATCH] psplash: add option to read startup message from file

2016-05-25 Thread Richard Leitner

Any comments/updates on that patch of mine?


On 04/15/2016 10:49 AM, Richard Leitner wrote:
> This patch adds an option to read the displayed message from a file.
> Additionally the maximum length for the read string can be defined.
> If both, a message (STARTUP_MSG) and a file (STARTUP_MSG_FILE) are
> defined the content of the file will be appended to the message.
> The string will be cutted after the given maximum number of chars.
> 
> For these changes the following defines were introduced:
>   PSPLASH_STARTUP_MSG_MAX_LEN ... maximum lenght of the complete message
>   PSPLASH_STARTUP_MSG_FILE .. path to the file to read
> 
> Signed-off-by: Richard Leitner 
> ---
>  psplash-config.h |  5 +
>  psplash.c| 29 -
>  2 files changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/psplash-config.h b/psplash-config.h
> index 82bb76d..7fa44fa 100644
> --- a/psplash-config.h
> +++ b/psplash-config.h
> @@ -21,6 +21,11 @@
>  
>  /* Text to output on program start; if undefined, output nothing */
>  #define PSPLASH_STARTUP_MSG ""
> +#define PSPLASH_STARTUP_MSG_MAX_LEN 32
> +
> +/* File to read and display its first line on program start;
> + * if undefined, output nothing; if MSG is defined also, append to it */
> +#define PSPLASH_STARTUP_MSG_FILE ""
>  
>  /* Bool indicating if the image is fullscreen, as opposed to split screen */
>  #define PSPLASH_IMG_FULLSCREEN 0
> diff --git a/psplash.c b/psplash.c
> index 04d3d49..b7d2d28 100644
> --- a/psplash.c
> +++ b/psplash.c
> @@ -208,6 +208,9 @@ main (int argc, char** argv)
>intpipe_fd, i = 0, angle = 0, ret = 0;
>PSplashFB *fb;
>bool   disable_console_switch = FALSE;
> +  char   msg[PSPLASH_STARTUP_MSG_MAX_LEN];
> +  intmsglen;
> +  FILE  *fd_msg;
>
>signal(SIGHUP, psplash_exit);
>signal(SIGINT, psplash_exit);
> @@ -298,9 +301,33 @@ main (int argc, char** argv)
>  
>psplash_draw_progress (fb, 0);
>  
> +  memset(msg, 0, PSPLASH_STARTUP_MSG_MAX_LEN);
> +  msglen = 0;
>  #ifdef PSPLASH_STARTUP_MSG
> -  psplash_draw_msg (fb, PSPLASH_STARTUP_MSG);
> +  snprintf(msg, PSPLASH_STARTUP_MSG_MAX_LEN, "%s", PSPLASH_STARTUP_MSG);
> +  msglen = strlen(msg);
>  #endif
> +#ifdef PSPLASH_STARTUP_MSG_FILE
> +  fd_msg = fopen (PSPLASH_STARTUP_MSG_FILE, "r");
> +  if (fd_msg)
> +{
> +  if (msglen == 0)
> +{
> +  fgets (msg, PSPLASH_STARTUP_MSG_MAX_LEN, fd_msg);
> +}
> +  else
> +{
> +  fgets ([msglen + 1], PSPLASH_STARTUP_MSG_MAX_LEN - msglen - 1, 
> fd_msg);
> +  msg[msglen] = ' ';
> +}
> +  fclose (fd_msg);
> +}
> +  msglen = strlen(msg);
> +#endif
> +
> +  /* draw message if we have one */
> +  if (msglen > 0)
> +psplash_draw_msg (fb, msg);
>  
>psplash_main (fb, pipe_fd, 0);
>  
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [psplash][PATCH] Add fbdev option to set the proper /dev/fbX.

2016-05-25 Thread Richard Leitner

Hi Julien,
comments on the code are below.
On 05/22/2016 07:46 PM, Julien Gueytat wrote:
> It works exactly the same way than the angle parameter:
>  * --angle <-> /etc/rotation file
>  * --fbdev <-> /etc/fbdev file
> 
> Signed-off-by: Julien Gueytat 
> ---
>  psplash-fb.c | 16 ++--
>  psplash-fb.h |  4 ++--
>  psplash.c| 57 -
>  3 files changed, 44 insertions(+), 33 deletions(-)
> 
> diff --git a/psplash-fb.c b/psplash-fb.c
> index 8daaf6f..d344e5a 100644
> --- a/psplash-fb.c
> +++ b/psplash-fb.c
> @@ -99,18 +99,20 @@ attempt_to_change_pixel_format (PSplashFB *fb,
>  }
>  
>  PSplashFB*
> -psplash_fb_new (int angle)
> +psplash_fb_new (int angle, int fbdev_id)
>  {
>struct fb_var_screeninfo fb_var;
>struct fb_fix_screeninfo fb_fix;
>int  off;
> -  char*fbdev;
> +  char fbdev[9] = "/dev/fb0";
>  
>PSplashFB *fb = NULL;
>  
> -  fbdev = getenv("FBDEV");
> -  if (fbdev == NULL)
> -fbdev = "/dev/fb0";
> +  if (fbdev_id > 0 && fbdev_id < 10)
> +{
> +// Conversion from integer to ascii.
> +fbdev[7] = fbdev_id + 48;
> +}

You removed the possiblity to get the fb device from FBDEV!
Please don't to that as people may rely on that feature!

If you like to add a fbdev commandline option make sure it can co-exist
with the already available methods for setting this option.
And don't forget to add documentation!

>  
>if ((fb = malloc (sizeof(PSplashFB))) == NULL)
>  {

...

> @@ -205,35 +205,41 @@ int
>  main (int argc, char** argv) 
>  {
>char  *tmpdir;
> -  intpipe_fd, i = 0, angle = 0, ret = 0;
> +  intpipe_fd, i = 0, angle = 0, fbdev_id = 0, ret = 0;
>PSplashFB *fb;
>bool   disable_console_switch = FALSE;
> -  
> +
>signal(SIGHUP, psplash_exit);
>signal(SIGINT, psplash_exit);
>signal(SIGQUIT, psplash_exit);
>  
> -  while (++i < argc)
> -{
> -  if (!strcmp(argv[i],"-n") || !strcmp(argv[i],"--no-console-switch"))
> -{
> -   disable_console_switch = TRUE;
> -   continue;
> - }
> +  while (++i < argc) {
> +if (!strcmp(argv[i],"-n") || !strcmp(argv[i],"--no-console-switch"))
> +  {
> +disable_console_switch = TRUE;
> +continue;
> +  }
> +
> +if (!strcmp(argv[i],"-a") || !strcmp(argv[i],"--angle"))
> +  {
> +if (++i >= argc) goto fail;
> +angle = atoi(argv[i]);
> +continue;
> +  }
> +
> +if (!strcmp(argv[i],"-f") || !strcmp(argv[i],"--fbdev"))
> +  {
> +if (++i >= argc) goto fail;
> +fbdev_id = atoi(argv[i]);
> +continue;
> +  }
>  
> -  if (!strcmp(argv[i],"-a") || !strcmp(argv[i],"--angle"))
> -{
> -   if (++i >= argc) goto fail;
> -   angle = atoi(argv[i]);
> -   continue;
> - }
> -  
>  fail:
>fprintf(stderr, 
> -   "Usage: %s [-n|--no-console-switch][-a|--angle 
> <0|90|180|270>]\n", 
> -   argv[0]);
> +  "Usage: %s [-n|--no-console-switch][-a|--angle 
> <0|90|180|270>][-f|--fbdev <0..9>]\n", 
> +  argv[0]);
>exit(-1);
> -}
> +  }

Please use the same coding style everywhere in psplash.

Furthermore please avoid/remove trailing whitespaces in new/changed code

>  
>tmpdir = getenv("TMPDIR");
>  
> @@ -245,10 +251,10 @@ main (int argc, char** argv)
>if (mkfifo(PSPLASH_FIFO, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP))
>  {
>if (errno!=EEXIST) 
> - {
> -   perror("mkfifo");
> -   exit(-1);
> - }
> + {
> +   perror("mkfifo");
> +   exit(-1);
> + }
>  }

This change is irrelevant for new fbdev option.
Please send this whitespace fix as a separate patch.

>  
>pipe_fd = open (PSPLASH_FIFO,O_RDONLY|O_NONBLOCK);
> @@ -262,10 +268,11 @@ main (int argc, char** argv)
>if (!disable_console_switch)
>  psplash_console_switch ();
>  
> -  if ((fb = psplash_fb_new(angle)) == NULL) {
> +  if ((fb = psplash_fb_new(angle,fbdev_id)) == NULL)
> +{
> ret = -1;
> goto fb_fail;
> -  }
> +}
>  
>/* Clear the background with #ecece1 */
>psplash_fb_draw_rect (fb, 0, 0, fb->width, fb->height,
> 

IMHO in this case fixing the whitespace is fine because the if clause
needs to be adopted for the new option.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH 2/2] refpolicy-minimum_2.20151208: add systemd dependent policy modules

2016-05-25 Thread Shrikant Bobade

From: Shrikant Bobade 

with systemd enabled refpolicy-minimum build breaks due to missing dependent
policy modules, so add the dependent modules: clock, systemd, udev
conditionally based on DISTRO_FEATURES.

dependent systemd policy modules needed to fix these errors:

* Failed to resolve 'adjtime_t' in typeattributeset statement at line 138 of
 .. modules/100/init/cil

* Failed to resolve 'systemd_kmod_conf_t' in typeattributeset statement at
line 141 of.. moules/100/init/cil

* Failed to resolve 'udev_t' in typeattributeset statement at line 143 of
modules/100/init/cil semodule:  Failed!

Signed-off-by: Shrikant Bobade 
---
 recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb 
b/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb
index 47ed558..04ceadd 100644
--- a/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb
+++ b/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb
@@ -17,6 +17,8 @@ CORE_POLICY_MODULES = "unconfined \
application libraries miscfiles logging userdomain \
init mount modutils getty authlogin locallogin \
"
+#systemd dependent policy modules
+CORE_POLICY_MODULES += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
'clock systemd udev', '', d)}"
 
 # nscd caches libc-issued requests to the name service.
 # Without nscd.pp, commands want to use these caches will be blocked.
-- 
1.9.1

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

[yocto] [meta-selinux][PATCH 1/2] refpolicy_common.inc: enable conditional systemd support

2016-05-25 Thread Shrikant Bobade

From: Shrikant Bobade 

refpolicy now introduced systemd support using POLICY_SYSTEMD variable,
with systemd enabled setup we need the refpolicy with systemd support, so
enable systemd support based on DISTRO_FEATURES.

Signed-off-by: Shrikant Bobade 
---
 recipes-security/refpolicy/refpolicy_common.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/refpolicy/refpolicy_common.inc 
b/recipes-security/refpolicy/refpolicy_common.inc
index 6112c28..1d3b93f 100644
--- a/recipes-security/refpolicy/refpolicy_common.inc
+++ b/recipes-security/refpolicy/refpolicy_common.inc
@@ -40,7 +40,7 @@ POLICY_DISTRO ?= "redhat"
 POLICY_UBAC ?= "n"
 POLICY_UNK_PERMS ?= "allow"
 POLICY_DIRECT_INITRC ?= "n"
-POLICY_SYSTEMD ?= "n"
+POLICY_SYSTEMD ?= "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'y', 
'n', d)}"
 POLICY_MONOLITHIC ?= "n"
 POLICY_CUSTOM_BUILDOPT ?= ""
 POLICY_QUIET ?= "y"
-- 
1.9.1

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

Re: [yocto] [meta-security][PATCH] Use bb.utils.contains instead of base_contains because it is deprecated

Re: [linux-yocto] [PULL REQUEST] Broxton related backports for linux-yocto-4.4

Re: [yocto] [yocto-autobuilder][PATCH] GetLayerVersion.py: set new layer version only if cmd was sucessful and not already set

Re: [yocto] [yocto-autobuilder][PATCH] GetLayerVersion.py: set new layer version only if cmd was sucessful and not already set

[yocto] [yocto-autobuilder][PATCH] GetLayerVersion.py: set new layer version only if cmd was sucessful and not already set

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

Re: [linux-yocto] [PULL REQUEST] Broxton related backports for linux-yocto-4.4

Re: [yocto] mount bind /var/lib and package management

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

Re: [yocto] [meta-virtualization][PATCH] Use bb.utils.contains instead of base_contains because it is deprecated

[yocto] any pointers to a yocto-based image to use as a live install utility?

[yocto] [meta-virtualization][PATCH] Use bb.utils.contains instead of base_contains because it is deprecated

[yocto] [meta-security][PATCH] Use bb.utils.contains instead of base_contains because it is deprecated

Re: [yocto] [psplash][PATCH] psplash: add option to read startup message from file

Re: [yocto] [psplash][PATCH] Add fbdev option to set the proper /dev/fbX.

[yocto] [meta-selinux][PATCH 2/2] refpolicy-minimum_2.20151208: add systemd dependent policy modules

[yocto] [meta-selinux][PATCH 1/2] refpolicy_common.inc: enable conditional systemd support

26 matches

Site Navigation

Mail list logo

Footer information