Re: [yocto] [meta-raspberrypi][PATCH v4 0/5] Support for .dtbo files for dtb overlays, required by kernels 4.4.6+

[Herve Jourdain]

Hi Andrei,

I believe it still has not been merged...
Shall I send a ping?

Herve

-Original Message-
From: Andrei Gherzan [mailto:and...@gherzan.ro] 
Sent: mercredi 15 juin 2016 01:54
To: Herve Jourdain 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [meta-raspberrypi][PATCH v4 0/5] Support for .dtbo
files for dtb overlays, required by kernels 4.4.6+

On Tue, May 31, 2016 at 04:46:30AM +0800, Herve Jourdain wrote:
> v4: rebased
> For kernels 4.4.9+, the behavior for the device tree overlays loading has
been modified on RaspberryPi.
> For overlays, it loads .dtbo files, not .dtb anymore.
> Also, it does not check for -overlay extension, so the name of the overlay
that is placed in the "overlays" directory must be .dtbo,
instead of -overlay.dtb.
>
> This patch addresses the issue for kernels 4.4+, while keeping the same
behavior for older kernels.
> This patch must be used in conjunction with another patch to
meta/recipes-kernel/linux-dtb.inc, which will allow the processing of .dtbo
files for overlays, instead of only .dtb like before.
>

Is the poky patch merged? It doesn't seem it was.

--
Andrei Gherzan

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

Re: [linux-yocto] [PULL REQUEST] Watchdog parenting fix for linux-yocto-4.1

[Bruce Ashfield]

On 2016-06-13 9:59 PM, Yong, Jonathan wrote:

This series of 11 patches from Linus's tree fixes the parenting of
watchdog devices. To do that, a lot of OMAP watchdog fixes are pulled in
as dependencies.



I've grabbed the changes. After my sanity tests pass, I'll send
SRCREV updates.

Bruce


Adds Conexant Digicolor CX9 and STMicroelectronics LPC Watchdog.

https://github.com/jyong2/yocto-backports.git
branch: for-linux-yocto-4.1


Baruch Siach (1):
  watchdog: digicolor: driver for Conexant Digicolor CX92755 SoC

Lars Poeschel (3):
  watchdog: docs: omap_wdt also understands nowayout
  watchdog: omap_wdt: implement get_timeleft
  watchdog: omap_wdt: early_enable module parameter

Lee Jones (2):
  watchdog: st_wdt: Add new driver for ST's LPC Watchdog
  watchdog: st_wdt: Update IP layout information to include Clocksource

Peter Robinson (1):
  watchdog: omap_wdt: fix null pointer dereference

Pratyush Anand (1):
  Watchdog: Fix parent of watchdog_devices

S Twiss (1):
  watchdog: da9062: DA9062 watchdog driver

Uwe Kleine-König (2):
  watchdog: omap: use watchdog_init_timeout instead of open coding it
  watchdog: omap: put struct watchdog_device into driver data

 .../devicetree/bindings/watchdog/omap-wdt.txt  |   3 +
 Documentation/watchdog/watchdog-parameters.txt |   3 +
 drivers/misc/mei/wd.c  |   1 +
 drivers/watchdog/Kconfig   |  31 ++
 drivers/watchdog/Makefile  |   3 +
 drivers/watchdog/bcm2835_wdt.c |   1 +
 drivers/watchdog/bcm47xx_wdt.c |   1 +
 drivers/watchdog/bcm_kona_wdt.c|   1 +
 drivers/watchdog/coh901327_wdt.c   |   1 +
 drivers/watchdog/da9052_wdt.c  |   1 +
 drivers/watchdog/da9055_wdt.c  |   1 +
 drivers/watchdog/da9062_wdt.c  | 254 +++
 drivers/watchdog/da9063_wdt.c  |   1 +
 drivers/watchdog/davinci_wdt.c |   1 +
 drivers/watchdog/digicolor_wdt.c   | 206 
 drivers/watchdog/ep93xx_wdt.c  |   1 +
 drivers/watchdog/gpio_wdt.c|   1 +
 drivers/watchdog/ie6xx_wdt.c   |   1 +
 drivers/watchdog/intel-mid_wdt.c   |   1 +
 drivers/watchdog/jz4740_wdt.c  |   1 +
 drivers/watchdog/mena21_wdt.c  |   1 +
 drivers/watchdog/menf21bmc_wdt.c   |   1 +
 drivers/watchdog/omap_wdt.c|  78 +++--
 drivers/watchdog/omap_wdt.h|   1 +
 drivers/watchdog/orion_wdt.c   |   1 +
 drivers/watchdog/pnx4008_wdt.c |   1 +
 drivers/watchdog/qcom-wdt.c|   1 +
 drivers/watchdog/retu_wdt.c|   1 +
 drivers/watchdog/rt2880_wdt.c  |   1 +
 drivers/watchdog/s3c2410_wdt.c |   1 +
 drivers/watchdog/shwdt.c   |   1 +
 drivers/watchdog/sirfsoc_wdt.c |   1 +
 drivers/watchdog/sp805_wdt.c   |   1 +
 drivers/watchdog/st_lpc_wdt.c  | 345
+
 drivers/watchdog/stmp3xxx_rtc_wdt.c|   1 +
 drivers/watchdog/tegra_wdt.c   |   1 +
 drivers/watchdog/twl4030_wdt.c |   1 +
 drivers/watchdog/txx9wdt.c |   1 +
 drivers/watchdog/ux500_wdt.c   |   1 +
 drivers/watchdog/via_wdt.c |   1 +
 drivers/watchdog/wm831x_wdt.c  |   1 +
 drivers/watchdog/wm8350_wdt.c  |   1 +
 42 files changed, 923 insertions(+), 34 deletions(-)
 create mode 100644 drivers/watchdog/da9062_wdt.c
 create mode 100644 drivers/watchdog/digicolor_wdt.c
 create mode 100644 drivers/watchdog/st_lpc_wdt.c


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

Re: [linux-yocto] [PULL REQUEST] Watchdog parenting fix for linux-yocto-4.1

[Bruce Ashfield]

On 2016-06-14 2:28 AM, Yong, Jonathan wrote:

On 06/14/2016 09:59, Yong, Jonathan wrote:

This series of 11 patches from Linus's tree fixes the parenting of
watchdog devices. To do that, a lot of OMAP watchdog fixes are pulled in
as dependencies.

Adds Conexant Digicolor CX9 and STMicroelectronics LPC Watchdog.

https://github.com/jyong2/yocto-backports.git
branch: for-linux-yocto-4.1



These 2 branches should also go into linux-yocto-4.1 standard/base:
for-linux-yocto-4.1-core  (driver core backports from Linus's)
for-linux-yocto-4.1-power (CPU idle/powercap backports from Linus's)


Can you elaborate ? How many patches ? What are the shortlogs / diffstats ?

What testing was done ? And which boards are the target ?

Bruce



Thanks!



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

Re: [linux-yocto] [PATCH 0/2] Backport pinctrl/intel patches from mainline kernel into linux-yocto-4.1

[Bruce Ashfield]

On 2016-06-14 1:44 AM, Tan Jui Nee wrote:

Hi Bruce,

The patches are to backport Intel Broxton / Apollo Lake patches
that are available in the mainline Linux kernel, upstreamed by
Qipeng Zha.

The patches are to fix GPIO register offset calculation for Intel
Broxton / Apollo Lake.

The patches are targetted to merge into linux-yocto-4.1 on
standard/base branch.

Please review and provide feedback if any.


These look fine. I've staged them on the tree.

Bruce



Thanks and best regards,
Juinee

Qipeng Zha (2):
  pinctrl: intel: fix bug of register offset calculation
  pinctrl: intel: fix offset calculation issue of register PAD_OWN

 drivers/pinctrl/intel/pinctrl-broxton.c  |  1 +
 drivers/pinctrl/intel/pinctrl-intel.c| 41 ++--
 drivers/pinctrl/intel/pinctrl-intel.h|  3 ++
 drivers/pinctrl/intel/pinctrl-sunrisepoint.c |  1 +
 4 files changed, 25 insertions(+), 21 deletions(-)



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

Re: [linux-yocto] [PATCH 0/8] TPM 2.0 support for linux-yocto-4.1

[Bruce Ashfield]

On 2016-06-14 12:14 AM, jonathan.y...@intel.com wrote:

From: "Yong, Jonathan" 

These patches introduces TPM 2.0 support, and are backported from Linus's tree.
Should apply cleanly for linux-yocto-4.1 stadard/base.



They do apply cleanly.

I've staged them in my tree, and will do some build testing.

Bruce


Jarkko Sakkinen (8):
  tpm, tpm_crb: fix unaligned read of the command buffer address
  tpm: move the PPI attributes to character device directory.
  tpm: introduce tpm_buf
  keys, trusted: move struct trusted_key_options to trusted-type.h
  tpm: seal/unseal for TPM 2.0
  keys, trusted: seal/unseal with TPM 2.0 chips
  tpm: fix missing migratable flag in sealing functionality for TPM2
  sysfs: added __compat_only_sysfs_link_entry_to_kobj()

 drivers/char/tpm/tpm-chip.c  |  24 ++--
 drivers/char/tpm/tpm-interface.c |  76 
 drivers/char/tpm/tpm.h   | 127 +--
 drivers/char/tpm/tpm2-cmd.c  | 255 ++-
 drivers/char/tpm/tpm_crb.c   |   7 +-
 drivers/char/tpm/tpm_ppi.c   |  34 ++
 fs/sysfs/group.c |  44 +++
 include/keys/trusted-type.h  |  14 ++-
 include/linux/sysfs.h|  11 ++
 include/linux/tpm.h  |  26 
 security/keys/trusted.c  |  36 +-
 security/keys/trusted.h  |  11 --
 12 files changed, 604 insertions(+), 61 deletions(-)



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

Re: [linux-yocto] [PATCH] MAINTAINER file update for TPM 2.0 series

[Bruce Ashfield]

On 2016-06-14 12:18 AM, jonathan.y...@intel.com wrote:

From: "Yong, Jonathan" 

Oops, missed this commit, this should be part of the
TPM 2.0 series. For linux-yocto-4.1 standard/base.


No worries. I've added it to the queue.

Bruce



Jarkko Sakkinen (1):
  MAINTAINERS: add new maintainer for TPM DEVICE DRIVER

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)



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

Re: [linux-yocto] [PATCH] powercap/RAPL: disable the 2nd power limit properly

[Bruce Ashfield]

On 2016-06-13 8:29 AM, ong.hock...@intel.com wrote:

From: "Yu, Ong Hock" 

This patch back port the upstream patch to properly handle the 2nd RAPL limit. 
This patch is intended for kernel 4.1.



I've staged the patch. Once my sanity builds have passed, I'll
send SRCREV updates.

Bruce


Seiichi Ikarashi (1):
  powercap / RAPL: disable the 2nd power limit properly

 drivers/powercap/intel_rapl.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)



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

Re: [yocto] [meta-raspberrypi][PATCH 1/6] linux-raspberrypi: Allow override of PV

[Andrei Gherzan]

On Fri, Jun 03, 2016 at 08:47:45PM +0100, Paul Barker wrote:
> On Fri, 3 Jun 2016 09:07:37 +0300
> Ionel Badisor  wrote:
>
> > On 06/03/2016 12:25 AM, Paul Barker wrote:
> > > On Thu, 2 Jun 2016 10:59:37 +0300
> > > Ionel Badisor  wrote:
> > >
> > >> On 06/01/2016 08:55 PM, Paul Barker wrote:
> > >>> On Tue, 31 May 2016 10:39:03 +0300
> > >>> Khem Raj  wrote:
> > >>>
> >  On May 30, 2016 3:15 PM, "Paul Barker" 
> >  wrote:
> > >
> > >
> > > I'm trying to build from a source archive instead of a git
> > > repository (to avoid a ~1.3GB git clone operation) so the use of
> > > ${SRCPV} is causing me trouble.
> > >
> > 
> >  Can you override the whole PV
> > >>>
> > >>> I've given this another look and I can get the recipe to parse if
> > >>> I require linux-raspberrypi.inc before setting PV instead of
> > >>> afterwards. However do_kernel_configme then gets confused looking
> > >>> for a "standard/raspberrypi" configuration. It only works if I
> > >>> modify linux-raspberrypi.inc as per my patch and set PV before
> > >>> requiring that include file.
> > >>>
> > >>> I'm starting to think that I might be doing something wrong here -
> > >>> is there a supported way to build a kernel from an archive instead
> > >>> of a git repository within OE?
> > >>>
> > >>> Thanks,
> > >>> Paul Barker
> > >>>
> > >> Are you trying to avoid repeated cloning operation to save bandwith
> > >> and time or you are trying to save disk space?
> > >
> > > I'm trying to reduce "time to first build" on a new build machine as
> > > well as the amount of space/bandwidth needed to mirror downloaded
> > > files.
> > >
> > > Instead of setting PV in each recipe I could just duplicate
> > > linux-raspberrypi.inc into my own layer with the change I need.
> > > That's probably the simplest approach for now, I'll just have to
> > > keep my eye on meta-raspberrypi going forward for any changes to
> > > linux-raspberrypi.inc which I'd need to incorporate.
> > >
> > Maybe you can use the `DL_DIR ?= "/path/to/downloads/"` in your
> > conf/local.conf file for multiple build directories and if you want
> > you can copy downloads directory to new machine and point to it the
> > new local.conf  then all do_fetch operations are already performed,
> > except new changes in which case the git fetch operation is performed
> > when git is used and takes less time then when fetching entire
> > archive.
> >
> > note: multiple builds on same machine can use same downloads
> > directory.
>
> I'm planning to release this as part of a distro layer in the future.
> Not all build machines will be under my control if others use the
> layer.
>
> I'm going to drop this patch for now as I can maintain my own copy of
> linux-raspberrypi.inc. I think it'd be good to get the other changes
> into master.
>
> V2 incoming.

I managed to follow the discussion. Sorry for my last reply on this.

I don't think the solution would be to manage a custom inc file. We need
to find a solution with this. Can I see and try your changes for the
arhive?

--
Andrei Gherzan


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

Re: [yocto] [meta-raspberrypi][PATCH 1/6] linux-raspberrypi: Allow override of PV

[Andrei Gherzan]

On Sun, May 29, 2016 at 04:59:08PM +0100, Paul Barker wrote:
> PV is now set in each version of the linux-raspberrypi recipe instead of in
> linux-raspberrypi.inc. This allows linux-raspberrypi.inc to be used in custom
> kernel recipes in another layer which require a different PV value.
>
> Signed-off-by: Paul Barker 
> ---
>  recipes-kernel/linux/linux-raspberrypi.inc | 1 -
>  recipes-kernel/linux/linux-raspberrypi_3.18.bb | 1 +
>  recipes-kernel/linux/linux-raspberrypi_4.1.bb  | 1 +
>  recipes-kernel/linux/linux-raspberrypi_4.4.bb  | 1 +
>  4 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
> b/recipes-kernel/linux/linux-raspberrypi.inc
> index 4799c74..dd477cd 100644
> --- a/recipes-kernel/linux/linux-raspberrypi.inc
> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
> @@ -13,7 +13,6 @@ SRC_URI += " \
>  COMPATIBLE_MACHINE = "raspberrypi"
>
>  PE = "1"
> -PV = "${LINUX_VERSION}+git${SRCPV}"
>
>  # NOTE: For now we pull in the default config from the RPi kernel GIT tree.
>  KERNEL_DEFCONFIG_raspberrypi ?= "bcmrpi_defconfig"
> diff --git a/recipes-kernel/linux/linux-raspberrypi_3.18.bb 
> b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
> index 1110b71..b16a1d7 100644
> --- a/recipes-kernel/linux/linux-raspberrypi_3.18.bb
> +++ b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
> @@ -1,6 +1,7 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
>  LINUX_VERSION ?= "3.18.16"
> +PV = "${LINUX_VERSION}+git${SRCPV}"
>
>  SRCREV = "1bb18c8f721ef674a447f3622273f2e2de7a205c"
>  SRC_URI = 
> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.18.y \
> diff --git a/recipes-kernel/linux/linux-raspberrypi_4.1.bb 
> b/recipes-kernel/linux/linux-raspberrypi_4.1.bb
> index 79fac66..9e1572e 100644
> --- a/recipes-kernel/linux/linux-raspberrypi_4.1.bb
> +++ b/recipes-kernel/linux/linux-raspberrypi_4.1.bb
> @@ -1,6 +1,7 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
>  LINUX_VERSION ?= "4.1.21"
> +PV = "${LINUX_VERSION}+git${SRCPV}"
>
>  SRCREV = "ff45bc0e8917c77461b2901e2743e6339bb70413"
>  SRC_URI = 
> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.1.y \
> diff --git a/recipes-kernel/linux/linux-raspberrypi_4.4.bb 
> b/recipes-kernel/linux/linux-raspberrypi_4.4.bb
> index ba47b22..12bb43a 100644
> --- a/recipes-kernel/linux/linux-raspberrypi_4.4.bb
> +++ b/recipes-kernel/linux/linux-raspberrypi_4.4.bb
> @@ -1,6 +1,7 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
>  LINUX_VERSION ?= "4.4.9"
> +PV = "${LINUX_VERSION}+git${SRCPV}"
>
>  SRCREV = "3b440738b5c1adc3ec3ee72ceca799d1b8d264df"
>  SRC_URI = 
> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.4.y \

I'm not really happy in duplicating PV. Wouldn't a weak assignment work
for you? PV ?= "${LINUX_VERSION}+git${SRCPV}" . So you can overwrite it
as you want.

--
Andrei Gherzan


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

Re: [yocto] [meta-raspberrypi][PATCH v4 3/5] rpi-base.inc: support for .dtbo files for dtb overlays

[Andrei Gherzan]

On Tue, May 31, 2016 at 04:46:33AM +0800, Herve Jourdain wrote:
> Kernel 4.4.6+ on RaspberryPi support .dtbo files for overlays, instead of 
> .dtb.
> Add support for both variants of overlays ("-overlay.dtb" and ".dtbo") for 
> the default KERNEL_DEVICETREE variable
>
> Signed-off-by: Herve Jourdain 
> ---
>  conf/machine/include/rpi-base.inc | 36 +++-
>  1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/conf/machine/include/rpi-base.inc 
> b/conf/machine/include/rpi-base.inc
> index 56ca83e..2c9d8e0 100644
> --- a/conf/machine/include/rpi-base.inc
> +++ b/conf/machine/include/rpi-base.inc
> @@ -16,7 +16,7 @@ XSERVER = " \
>  "
>
>  # Really supported starting from linux-raspberrypi 3.18.y only
> -KERNEL_DEVICETREE ?= " \
> +KERNEL_DEVICETREE_OVERLAYS_DTB = " \
>  bcm2708-rpi-b.dtb \
>  bcm2708-rpi-b-plus.dtb \
>  bcm2709-rpi-2-b.dtb \
> @@ -38,6 +38,40 @@ KERNEL_DEVICETREE ?= " \
>  overlays/w1-gpio-pullup-overlay.dtb \
>  overlays/pi3-miniuart-bt-overlay.dtb \
>  "
> +KERNEL_DEVICETREE_OVERLAYS_DTBO = " \
> +bcm2708-rpi-b.dtb \
> +bcm2708-rpi-b-plus.dtb \
> +bcm2709-rpi-2-b.dtb \
> +bcm2710-rpi-3-b.dtb \
> +\
> +overlays/hifiberry-amp.dtbo \
> +overlays/hifiberry-dac.dtbo \
> +overlays/hifiberry-dacplus.dtbo \
> +overlays/hifiberry-digi.dtbo \
> +overlays/i2c-rtc.dtbo \
> +overlays/iqaudio-dac.dtbo \
> +overlays/iqaudio-dacplus.dtbo \
> +overlays/lirc-rpi.dtbo \
> +overlays/pitft22.dtbo \
> +overlays/pitft28-resistive.dtbo \
> +overlays/pps-gpio.dtbo \
> +overlays/rpi-ft5406.dtbo \
> +overlays/w1-gpio.dtbo \
> +overlays/w1-gpio-pullup.dtbo \
> +overlays/pi3-miniuart-bt.dtbo \
> +"
> +
> +def cmpver_strings(ver1, ver2, truevalue, falsevalue):
> +from distutils.version import LooseVersion
> +ver1 = ''.join(ch for ch in ver1 if ch in '0123456789.')
> +ver2 = ''.join(ch for ch in ver2 if ch in '0123456789.')
> +if LooseVersion(ver1) >= LooseVersion(ver2):
> +return truevalue
> +else:
> +return falsevalue
> +
> +KERNEL_DEVICETREE ?= 
> "${@cmpver_strings("${PREFERRED_VERSION_linux-raspberrypi}", "4.4", 
> "${KERNEL_DEVICETREE_OVERLAYS_DTBO}", "${KERNEL_DEVICETREE_OVERLAYS_DTB}")}"
> +
>  KERNEL_IMAGETYPE ?= "Image"
>

Can we avoid this duplication by translating dtbo->dtb for kernels
before 4.4? And I would suggest doing this in
linux-raspberrypi-base.bbclass . What do you think? We should reuse code
there for version too.

>  MACHINE_FEATURES += "apm usbhost keyboard vfat ext2 screen touchscreen alsa 
> bluetooth wifi sdio"
> --
> 2.7.4
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

--
Andrei Gherzan


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

Re: [yocto] [meta-raspberrypi][PATCH v4 4/5] linux-raspberrypi_4.4.inc: support for .dtbo files for dtb overlays

[Andrei Gherzan]

On Tue, May 31, 2016 at 04:46:34AM +0800, Herve Jourdain wrote:
> Kernel 4.4.6+ on RaspberryPi support .dtbo files for overlays, instead of 
> .dtb.
> Patch the kernel, which has faulty rules to generate .dtbo the way yocto does
>

You need an Upstream status here:
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
I think this would be interesting to send upstream too.

> Signed-off-by: Herve Jourdain 
> ---
>  .../0001-fix-dtbo-rules.patch  | 27 
> ++
>  1 file changed, 27 insertions(+)
>  create mode 100644 
> recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
>
> diff --git 
> a/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch 
> b/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
> new file mode 100644
> index 000..ef04a72
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
> @@ -0,0 +1,27 @@
> +diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> +index a2e7cf7..673c1cb 100644
> +--- a/arch/arm/Makefile
>  b/arch/arm/Makefile
> +@@ -333,6 +333,8 @@ $(INSTALL_TARGETS):
> +
> + %.dtb: | scripts
> + $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@
> ++%.dtbo: | scripts
x> ++   $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@
> +
> + PHONY += dtbs dtbs_install
> +
> +diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> +index 3079c4f..6cc3766 100644
> +--- a/scripts/Makefile.lib
>  b/scripts/Makefile.lib
> +@@ -293,7 +293,8 @@ $(obj)/%.dtb: $(src)/%.dts FORCE
> + $(call if_changed_dep,dtc)
> +
> + quiet_cmd_dtco = DTCO$@
> +-cmd_dtco = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; 
> \
> ++cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
> ++$(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
> + $(objtree)/scripts/dtc/dtc -@ -H epapr -O dtb -o $@ -b 0 \
> + -i $(dir $<) $(DTC_FLAGS) \
> + -d $(depfile).dtc.tmp $(dtc-tmp) ; \
> --
> 2.7.4
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

--
Andrei Gherzan


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

Re: [yocto] [meta-raspberrypi][PATCH v4 5/5] linux-raspberrypi_4.4.inc: support for .dtbo files for dtb overlays

[Andrei Gherzan]

On Tue, May 31, 2016 at 04:46:35AM +0800, Herve Jourdain wrote:
> Signed-off-by: Herve Jourdain 
> ---
>  recipes-kernel/linux/linux-raspberrypi_4.4.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi_4.4.bb 
> b/recipes-kernel/linux/linux-raspberrypi_4.4.bb
> index ba47b22..789fef1 100644
> --- a/recipes-kernel/linux/linux-raspberrypi_4.4.bb
> +++ b/recipes-kernel/linux/linux-raspberrypi_4.4.bb
> @@ -4,5 +4,6 @@ LINUX_VERSION ?= "4.4.9"
>
>  SRCREV = "3b440738b5c1adc3ec3ee72ceca799d1b8d264df"
>  SRC_URI = 
> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.4.y \
> +   file://0001-fix-dtbo-rules.patch \
>  "
>  require linux-raspberrypi.inc
> --
> 2.7.4
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Can we merge this patch in the 4th one? Only if you decide to push
another version based on other comments.

--
Andrei Gherzan


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

Re: [yocto] [meta-raspberrypi][PATCH v4 0/5] Support for .dtbo files for dtb overlays, required by kernels 4.4.6+

[Andrei Gherzan]

On Tue, May 31, 2016 at 04:46:30AM +0800, Herve Jourdain wrote:
> v4: rebased
> For kernels 4.4.9+, the behavior for the device tree overlays loading has 
> been modified on RaspberryPi.
> For overlays, it loads .dtbo files, not .dtb anymore.
> Also, it does not check for -overlay extension, so the name of the overlay 
> that is placed in the "overlays" directory must be .dtbo, 
> instead of -overlay.dtb.
>
> This patch addresses the issue for kernels 4.4+, while keeping the same 
> behavior for older kernels.
> This patch must be used in conjunction with another patch to 
> meta/recipes-kernel/linux-dtb.inc, which will allow the processing of .dtbo 
> files for overlays, instead of only .dtb like before.
>

Is the poky patch merged? It doesn't seem it was.

--
Andrei Gherzan


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

Re: [yocto] [meta-raspberrypi][PATCH 1/1] linux-raspberrypi.inc: KERNEL_OUTPUT has been removed in kernel.bbclass

[Andrei Gherzan]

Hi,

On Tue, May 31, 2016 at 07:58:59PM +0800, Herve Jourdain wrote:
> Signed-off-by: Herve Jourdain 
> ---
>  recipes-kernel/linux/linux-raspberrypi.inc | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
> b/recipes-kernel/linux/linux-raspberrypi.inc
> index 4799c74..6133b02 100644
> --- a/recipes-kernel/linux/linux-raspberrypi.inc
> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
> @@ -66,7 +66,9 @@ do_rpiboot_mkimage() {
>  if test "x${KERNEL_IMAGETYPE}" != "xuImage" ; then
>  if test -n "${KERNEL_DEVICETREE}"; then
>  # Add RPi bootloader trailer to kernel image to enable 
> DeviceTree support
> -${STAGING_BINDIR_NATIVE}/mkknlimg --dtok ${KERNEL_OUTPUT} 
> ${KERNEL_OUTPUT}
> +for type in ${KERNEL_IMAGETYPES} ; do
> +${STAGING_BINDIR_NATIVE}/mkknlimg --dtok 
> ${KERNEL_OUTPUT_DIR}/$type ${KERNEL_OUTPUT_DIR}/$type
> +done
>  fi
>  fi
>  }
> @@ -76,7 +78,9 @@ do_bundle_initramfs_append() {
>  if test "x${KERNEL_IMAGETYPE}" != "xuImage" ; then
>  if test -n "${KERNEL_DEVICETREE}"; then
>  # Add RPi bootloader trailer to kernel image to enable 
> DeviceTree support
> -${STAGING_BINDIR_NATIVE}/mkknlimg --dtok 
> ${KERNEL_OUTPUT}.initramfs ${KERNEL_OUTPUT}.initramfs
> +for type in ${KERNEL_IMAGETYPES} ; do
> +${STAGING_BINDIR_NATIVE}/mkknlimg --dtok 
> ${KERNEL_OUTPUT_DIR}/$type.initramfs ${KERNEL_OUTPUT_DIR}/$type.initramfs
> +done
>  fi
>  fi
>  fi
> --
> 2.7.4
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Merged to master. Thanks.

--
Andrei Gherzan


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

[yocto] [PATCH 2/2] linux-raspberrypi: Fix v4.1 with GCC6

[Andrei Gherzan]

Signed-off-by: Andrei Gherzan 
---
 ...ove-unused-sm_cache_map_vector-definition.patch | 31 +
 .../linux-raspberrypi-4.1/0003-fix-gcc6.patch  | 78 ++
 recipes-kernel/linux/linux-raspberrypi_4.1.bb  |  2 +
 3 files changed, 111 insertions(+)
 create mode 100644 
recipes-kernel/linux/linux-raspberrypi-4.1/0002-vmcs-Remove-unused-sm_cache_map_vector-definition.patch
 create mode 100644 
recipes-kernel/linux/linux-raspberrypi-4.1/0003-fix-gcc6.patch

diff --git 
a/recipes-kernel/linux/linux-raspberrypi-4.1/0002-vmcs-Remove-unused-sm_cache_map_vector-definition.patch
 
b/recipes-kernel/linux/linux-raspberrypi-4.1/0002-vmcs-Remove-unused-sm_cache_map_vector-definition.patch
new file mode 100644
index 000..8d4a900
--- /dev/null
+++ 
b/recipes-kernel/linux/linux-raspberrypi-4.1/0002-vmcs-Remove-unused-sm_cache_map_vector-definition.patch
@@ -0,0 +1,31 @@
+The code using it also ifdef'ed with 0, anyyd gcc 6
+complains
+
+error: 'sm_cache_map_vector' defined but not used
+
+The code using it also ifdef'ed out
+
+Upstream-status: Denied [https://github.com/raspberrypi/linux/pull/1528]
+
+Signed-off-by: Khem Raj 
+---
+ drivers/char/broadcom/vc_sm/vmcs_sm.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/char/broadcom/vc_sm/vmcs_sm.c
 b/drivers/char/broadcom/vc_sm/vmcs_sm.c
+@@ -197,12 +197,14 @@ struct SM_STATE_T {
+ static struct SM_STATE_T *sm_state;
+ static int sm_inited;
+ 
++#if 0
+ static const char *const sm_cache_map_vector[] = {
+   "(null)",
+   "host",
+   "videocore",
+   "host+videocore",
+ };
++#endif
+ 
+ /*  Private Function Prototypes -- */
+ 
diff --git a/recipes-kernel/linux/linux-raspberrypi-4.1/0003-fix-gcc6.patch 
b/recipes-kernel/linux/linux-raspberrypi-4.1/0003-fix-gcc6.patch
new file mode 100644
index 000..61ec2fb
--- /dev/null
+++ b/recipes-kernel/linux/linux-raspberrypi-4.1/0003-fix-gcc6.patch
@@ -0,0 +1,78 @@
+Fix compile with GCC6
+
+Upstream-status: Denied [https://github.com/raspberrypi/linux/pull/1528]
+
+Signed-off-by: Andrei Gherzan 
+
+Index: source/include/linux/compiler-gcc6.h
+===
+--- /dev/null
 source/include/linux/compiler-gcc6.h
+@@ -0,0 +1,67 @@
++#ifndef __LINUX_COMPILER_H
++#error "Please don't include  directly, include 
 instead."
++#endif
++
++#define __used__attribute__((__used__))
++#define __must_check  __attribute__((warn_unused_result))
++#define __compiler_offsetof(a, b) __builtin_offsetof(a, b)
++
++/* Mark functions as cold. gcc will assume any path leading to a call
++   to them will be unlikely.  This means a lot of manual unlikely()s
++   are unnecessary now for any paths leading to the usual suspects
++   like BUG(), printk(), panic() etc. [but let's keep them for now for
++   older compilers]
++
++   Early snapshots of gcc 4.3 don't support this and we can't detect this
++   in the preprocessor, but we can live with this because they're unreleased.
++   Maketime probing would be overkill here.
++
++   gcc also has a __attribute__((__hot__)) to move hot functions into
++   a special section, but I don't see any sense in this right now in
++   the kernel context */
++#define __cold__attribute__((__cold__))
++
++#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), 
__COUNTER__)
++
++#ifndef __CHECKER__
++# define __compiletime_warning(message) __attribute__((warning(message)))
++# define __compiletime_error(message) __attribute__((error(message)))
++#endif /* __CHECKER__ */
++
++/*
++ * Mark a position in code as unreachable.  This can be used to
++ * suppress control flow warnings after asm blocks that transfer
++ * control elsewhere.
++ *
++ * Early snapshots of gcc 4.5 don't support this and we can't detect
++ * this in the preprocessor, but we can live with this because they're
++ * unreleased.  Really, we need to have autoconf for the kernel.
++ */
++#define unreachable() __builtin_unreachable()
++
++/* Mark a function definition as prohibited from being cloned. */
++#define __noclone __attribute__((__noclone__))
++
++/*
++ * Tell the optimizer that something else uses this function or variable.
++ */
++#define __visible __attribute__((externally_visible))
++
++/*
++ * GCC 'asm goto' miscompiles certain code sequences:
++ *
++ *   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
++ *
++ * Work it around via a compiler barrier quirk suggested by Jakub Jelinek.
++ *
++ * (asm goto is automatically volatile - the naming reflects this.)
++ */
++#define asm_volatile_goto(x...)   do { asm goto(x); asm (""); } while (0)
++
++#ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
++#define __HAVE_BUILTIN_BSWAP32__
++#define __HAVE_BUILTIN_BSWAP64__
++#define __HAVE_BUILTIN_BSWAP16__
++#endif /* CONFIG_ARCH_USE_BUILTIN_BSWAP */
++
++#define 

[yocto] [PATCH 1/2] packagegroup-rpi-test: Poky moved the license so fix LIC_FILES_CHKSUM

[Andrei Gherzan]

Signed-off-by: Andrei Gherzan 
---
 recipes-core/packagegroups/packagegroup-rpi-test.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-core/packagegroups/packagegroup-rpi-test.bb 
b/recipes-core/packagegroups/packagegroup-rpi-test.bb
index ae16cec..a47aeb2 100644
--- a/recipes-core/packagegroups/packagegroup-rpi-test.bb
+++ b/recipes-core/packagegroups/packagegroup-rpi-test.bb
@@ -1,6 +1,6 @@
 DESCRIPTION = "RaspberryPi Test Packagegroup"
 LICENSE = "MIT"
-LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58"
+LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3f40d7994397109285ec7b81fdeb3b58"
 
 inherit packagegroup
 
-- 
2.8.2

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

Re: [yocto] Customization for nginx

[Elias Diem]

Hi Virgil

On 2016-06-14, Smith, Virgil wrote:


"How do you prefer a provider out of two different versions of a package?"

PREFERRED_VERSION
http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#var-PREFERRED_VERSION


Thanks. Worked fine.


--
Greetings
Elias


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

Re: [yocto] [[PATCH][error-report-web] 5/8] Post/models.py: Build model add support for Error type.

[Aníbal Limón]

On 06/14/2016 11:44 AM, Aníbal Limón wrote:
> 
> 
> On 06/14/2016 08:30 AM, Michael Wood wrote:
>> On 14/06/16 00:32, Aníbal Limón wrote:
>>> In order to support other errors not only Recipe ones adds
>>> a ERROR_TYPE field to the Build model defaults to "Recipe".
>>>
>>> Add a class for store BuildErrorType currently supported
>>> Recipe, Core, Bitbake selftest and OE selftest.
>>>
>>> [YOCTO #7583]
>>>
>>> Signed-off-by: Aníbal Limón 
>>> ---
>>>   Post/migrations/0005_build_error_type.py | 19 +++
>>>   Post/models.py   |  7 +++
>>>   2 files changed, 26 insertions(+)
>>>   create mode 100644 Post/migrations/0005_build_error_type.py
>>>
>>> diff --git a/Post/migrations/0005_build_error_type.py
>>> b/Post/migrations/0005_build_error_type.py
>>> new file mode 100644
>>> index 000..96cdf8c
>>> --- /dev/null
>>> +++ b/Post/migrations/0005_build_error_type.py
>>> @@ -0,0 +1,19 @@
>>> +# -*- coding: utf-8 -*-
>>> +from __future__ import unicode_literals
>>> +
>>> +from django.db import migrations, models
>>> +
>>> +
>>> +class Migration(migrations.Migration):
>>> +
>>> +dependencies = [
>>> +('Post', '0004_auto_20160530_1126'),
>>> +]
>>> +
>>> +operations = [
>>> +migrations.AddField(
>>> +model_name='build',
>>> +name='ERROR_TYPE',
>>> +field=models.CharField(default=b'Recipe', max_length=64),
>>> +),
>>> +]
>>> diff --git a/Post/models.py b/Post/models.py
>>> index 84f8abf..f8d9916 100644
>>> --- a/Post/models.py
>>> +++ b/Post/models.py
>>> @@ -11,6 +11,12 @@ from datetime import datetime
>>> import Levenshtein
>>>   +class BuildErrorType(object):
>>> +RECIPE = "Recipe"
>>> +BITBAKE_CORE = "Core"
>>> +BITBAKE_SELFTEST = "Bitbake selftest"
>>> +OE_SELFTEST = "OE selftest"
>>> +
>>>   # Create your models here.
>>>   class Build(models.Model):
>>>   DATE = models.DateTimeField('Submit date', blank=True, null=True)
>>> @@ -25,6 +31,7 @@ class Build(models.Model):
>>>   NAME = models.CharField(max_length=50)
>>>   EMAIL = models.CharField(max_length=50)
>>>   LINK_BACK = models.TextField(max_length=300, blank=True, null=True)
>>> +ERROR_TYPE = models.CharField(max_length=64,
>>> default=BuildErrorType.RECIPE)
>>> class BuildFailure(models.Model):
>>>   TASK = models.CharField(max_length=1024)
>>
>> Thanks for the patches.
>>
>> Ideally we wouldn't use a char field here as if the type string ever
>> changed the database could end up with multiple versions of the type
>> strings depending on when the type was saved, it would be possible to
>> handle that with migrations but it would be pretty messy. It also allows
>> any arbitrary chars which we probably don't want if it's something we're
>> going to be filtering on.  Here is an example from Toaster on how it can
>> be done with the choices option and an enum style.
>>
>> |OUTCOME_NA = -1 OUTCOME_SUCCESS = 0 OUTCOME_COVERED = 1 OUTCOME_CACHED
>> = 2 OUTCOME_PREBUILT = 3 OUTCOME_FAILED = 4 OUTCOME_EMPTY = 5
>> TASK_OUTCOME = ( (OUTCOME_NA, 'Not Available'), (OUTCOME_SUCCESS,
>> 'Succeeded'), (OUTCOME_COVERED, 'Covered'), (OUTCOME_CACHED, 'Cached'),
>> (OUTCOME_PREBUILT, 'Prebuilt'), (OUTCOME_FAILED, 'Failed'),
>> (OUTCOME_EMPTY, 'Empty'), ) ||outcome =
>> models.IntegerField(choices=TASK_OUTCOME, default=OUTCOME_NA)|
>>
> 
> Thanks for the feedback, i'll change to use choices instead of char values.
> 
>   alimon

I made the change now is at contrib branch,

http://git.yoctoproject.org/cgit/cgit.cgi/error-report-web/log/?h=alimon/devel

alimon

> 
>>
>>
>> Michael
>>
> 
> 
> 



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

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi: Prevent taskhash mismatch

[Andrei Gherzan]

Hi Paul,

On Wed, Jun 08, 2016 at 02:02:29PM +0100, Paul Barker wrote:
> As recently discussed on the mailing list, bitbake now issues an error when 
> the
> task hash computed by the bitbake master differs from the task hash computed 
> by
> the bitbake worker. This usually happens when the task hash depends on the 
> date
> and time for some reason.
>
> This affects IMAGE_CMD_rpi-sdimg and is fixed by excluding the dependency on 
> the
> current date and time from the command.
>
> Signed-off-by: Paul Barker 
> ---
>  classes/sdcard_image-rpi.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/classes/sdcard_image-rpi.bbclass 
> b/classes/sdcard_image-rpi.bbclass
> index 3b4f13f..a8d83a3 100644
> --- a/classes/sdcard_image-rpi.bbclass
> +++ b/classes/sdcard_image-rpi.bbclass
> @@ -72,7 +72,7 @@ SDIMG = "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.rpi-sdimg"
>  FATPAYLOAD ?= ""
>
>  IMAGEDATESTAMP = "${@time.strftime('%Y.%m.%d',time.gmtime())}"
> -IMAGE_CMD_rpi-sdimg[vardepsexclude] = "IMAGEDATESTAMP"
> +IMAGE_CMD_rpi-sdimg[vardepsexclude] = "DATETIME"
>
>  IMAGE_CMD_rpi-sdimg () {

I can't seem to replicate this issue with currrent poky master. Any idea
why? Maybe this got fixed in poky?



--
Andrei Gherzan


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

Re: [yocto] Customization for nginx

[Smith, Virgil]

"How do you prefer a provider out of two different versions of a package?"

PREFERRED_VERSION
http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#var-PREFERRED_VERSION




Notice to recipient: This email is meant for only the intended recipient of the 
transmission, and may be a communication privileged by law, subject to export 
control restrictions or that otherwise contains proprietary information. If you 
receive this email by mistake, please notify us immediately by replying to this 
message and then destroy it and do not review, disclose, copy or distribute it. 
Thank you in advance for your cooperation.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Customization for nginx

[Elias Diem]

Hi Piotr

On 2016-06-14, piotr.lewicki wrote:


This is not an answer to your question but it can be helpful:
You can use a wildcard for version in your bbappend file.
If you rename it to:

nginx_1.9.%.bbappend

this will work for both 1.9.5 and 1.9.14.


Thanks for this hint.

I realized that krogoth delivers two recipes for nginx:

1.9.14 and 1.8.1

And it picks 1.8.1. That's why it does not work.

Now I tried to set

PREFERRED_PROVIDER_nginx = "nginx-1.9.14"

But this does not seem to work.

How do you prefer a provider out of two different versions 
of a package?



--
Greetings
Elias


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

Re: [yocto] [yocto-autobuilder] [RFC] Add support for generate bitbake error reports

[Aníbal Limón]

On 06/14/2016 10:57 AM, Aníbal Limón wrote:
> 
> 
> On 06/14/2016 10:09 AM, Lock, Joshua G wrote:
>> On Thu, 2016-06-09 at 16:23 -0500, Aníbal Limón wrote:
>>> Hi folks,
>>>
>>> Currently we support to send error reports to errors.yoctoproject.org
>>> about failing tasks on bitbake using SendErrorReport buildstep but we
>>> have a lack of bitbake related errors like exceptions.
>>>
>>> A bug exist to implement this support into Error report web [1], i'm
>>> working on it but for generate bitbake error reports there's a need
>>> of
>>> some process monitoring the bitbake output in this case the Yocto
>>> Autobuilder.
>>>
>>> This email is for review my current implementation for generate
>>> bitbake
>>> error reports in the Autobuilder [2] next i'll try to explain how it
>>> works.
>>>
>>> I aadded a BitbakeShellCommand [3] class for use in the buildsteps
>>> that
>>> executes bitbake the main objective of this class is to have common
>>> operations to be made in bitbake commands like create error reports
>>> if
>>> fails.
>>>
>>> For create error reports this class add an stdio observer to look at
>>> bitbake output and if bitbake fails review the bitbake output for
>>> identify if the failure is an non-related task error [4]. If the
>>> observer found bitbake error creates an Error report with the
>>> information in the master controller.
>>>
>>> In order to send the bitbake error to Error report web the controller
>>> transfer the report to the worker using a new DownloadDirectory
>>> implementation that i made [5], the SendErrorReport buildstep works
>>> on
>>> the worker side so it's easy to transfer the reports from master to
>>> worker instead of send it by master.
>>>
>>> Finally to complete with the job of have the bitbake errors reports
>>> the
>>> Error report web changes need  (i'm working on it) to be integrated
>>> first in order to don't break anything.
>>>
>>> Please review it and provide me feedback.
>>
>> This would've been much easier to review as a series of patches.
>>
>> After a quick read via the gitweb the series as a whole looks good.
>>
>> A couple of review comments:
>>
>> In a04b41d37c29191318386455d8d958ff815a3a10 "lib/buildsteps.py: Add
>> BitbakeLogLineObserver for BitbakeShellCommands." you have a comment
>>
>> "discard line that are not errors and line that is recipe task errors"
>>
>> but the lines are not actually discarded, afaict  from a cursory read
>> through they aren't used in the rest of the series
>> unless errors['bitbake'] == True? 
>>
>> Could we move the error['log'].append() to after the if statement which
>> checks whether this is a bitbake error?
> 
> Yes and i'll update the commit message to be more consistent.
> 
>>
>> Minor nit, in caf472bc696053227825c5a102feef3e17574ba2 "lib/buildsteps:
>> BitbakeShellCommand add support for create error reports"
>> in get_error_report_bitbake_dir() you use both " and ' for strings.
>>
>> Same in 40279597615c49bc4f4f067cbab937584b626671
> 
> I'll fix the typos for only use "".
> 
>   alimon
> 
I updated the branch with the changes suggested now at,

http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/log/?h=contrib/alimon/devel

alimon

>>
>> Regards,
>>
>> Joshua
>>
>>>
>>> Cheers,
>>> alimon
>>>
>>> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7583
>>> [2]
>>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/log/?h=co
>>> ntrib/alimon/devel
>>> [3]
>>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/tree/lib/
>>> python2.7/site-
>>> packages/autobuilder/lib/buildsteps.py?h=contrib/alimon/devel#n92
>>> [4]
>>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/tree/lib/
>>> python2.7/site-
>>> packages/autobuilder/lib/buildsteps.py?h=contrib/alimon/devel#n53
>>> [5]
>>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/commit/?h
>>> =contrib/alimon/devel=4022920bb0e56d1eef3dfe7c5e9b4699f801cdf1
> 
> 
> 



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

Re: [yocto] [meta-raspberrypi][PATCH] omxplayer: fix compilation with GCC 6

[Andrei Gherzan]

Hi,

On Wed, Jun 08, 2016 at 12:57:13AM +1000, Jonathan Liu wrote:
> Specifying -isystem${STAGING_DIR_HOST}/usr/include in INCLUDES gives:
>
> In file included from utils/PCMRemap.cpp:26:0:
> .../build/tmp/sysroots/raspberrypi2/usr/include/c++/6.1.1/cstdlib:75:25: 
> fatal error: stdlib.h: No such file or directory
>  #include_next 
>  ^
> compilation terminated.
> Makefile:44: recipe for target 'utils/PCMRemap.o' failed
>
> To resolve this, /usr/include shouldn't be specified as it is already a
> default include path relative to the sysroot.
>
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129.
>
> Signed-off-by: Jonathan Liu 

Pushed to master. Thanks.

--
Andrei Gherzan


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

Re: [yocto] [[PATCH][error-report-web] 5/8] Post/models.py: Build model add support for Error type.

[Aníbal Limón]

On 06/14/2016 08:30 AM, Michael Wood wrote:
> On 14/06/16 00:32, Aníbal Limón wrote:
>> In order to support other errors not only Recipe ones adds
>> a ERROR_TYPE field to the Build model defaults to "Recipe".
>>
>> Add a class for store BuildErrorType currently supported
>> Recipe, Core, Bitbake selftest and OE selftest.
>>
>> [YOCTO #7583]
>>
>> Signed-off-by: Aníbal Limón 
>> ---
>>   Post/migrations/0005_build_error_type.py | 19 +++
>>   Post/models.py   |  7 +++
>>   2 files changed, 26 insertions(+)
>>   create mode 100644 Post/migrations/0005_build_error_type.py
>>
>> diff --git a/Post/migrations/0005_build_error_type.py
>> b/Post/migrations/0005_build_error_type.py
>> new file mode 100644
>> index 000..96cdf8c
>> --- /dev/null
>> +++ b/Post/migrations/0005_build_error_type.py
>> @@ -0,0 +1,19 @@
>> +# -*- coding: utf-8 -*-
>> +from __future__ import unicode_literals
>> +
>> +from django.db import migrations, models
>> +
>> +
>> +class Migration(migrations.Migration):
>> +
>> +dependencies = [
>> +('Post', '0004_auto_20160530_1126'),
>> +]
>> +
>> +operations = [
>> +migrations.AddField(
>> +model_name='build',
>> +name='ERROR_TYPE',
>> +field=models.CharField(default=b'Recipe', max_length=64),
>> +),
>> +]
>> diff --git a/Post/models.py b/Post/models.py
>> index 84f8abf..f8d9916 100644
>> --- a/Post/models.py
>> +++ b/Post/models.py
>> @@ -11,6 +11,12 @@ from datetime import datetime
>> import Levenshtein
>>   +class BuildErrorType(object):
>> +RECIPE = "Recipe"
>> +BITBAKE_CORE = "Core"
>> +BITBAKE_SELFTEST = "Bitbake selftest"
>> +OE_SELFTEST = "OE selftest"
>> +
>>   # Create your models here.
>>   class Build(models.Model):
>>   DATE = models.DateTimeField('Submit date', blank=True, null=True)
>> @@ -25,6 +31,7 @@ class Build(models.Model):
>>   NAME = models.CharField(max_length=50)
>>   EMAIL = models.CharField(max_length=50)
>>   LINK_BACK = models.TextField(max_length=300, blank=True, null=True)
>> +ERROR_TYPE = models.CharField(max_length=64,
>> default=BuildErrorType.RECIPE)
>> class BuildFailure(models.Model):
>>   TASK = models.CharField(max_length=1024)
> 
> Thanks for the patches.
> 
> Ideally we wouldn't use a char field here as if the type string ever
> changed the database could end up with multiple versions of the type
> strings depending on when the type was saved, it would be possible to
> handle that with migrations but it would be pretty messy. It also allows
> any arbitrary chars which we probably don't want if it's something we're
> going to be filtering on.  Here is an example from Toaster on how it can
> be done with the choices option and an enum style.
> 
> |OUTCOME_NA = -1 OUTCOME_SUCCESS = 0 OUTCOME_COVERED = 1 OUTCOME_CACHED
> = 2 OUTCOME_PREBUILT = 3 OUTCOME_FAILED = 4 OUTCOME_EMPTY = 5
> TASK_OUTCOME = ( (OUTCOME_NA, 'Not Available'), (OUTCOME_SUCCESS,
> 'Succeeded'), (OUTCOME_COVERED, 'Covered'), (OUTCOME_CACHED, 'Cached'),
> (OUTCOME_PREBUILT, 'Prebuilt'), (OUTCOME_FAILED, 'Failed'),
> (OUTCOME_EMPTY, 'Empty'), ) ||outcome =
> models.IntegerField(choices=TASK_OUTCOME, default=OUTCOME_NA)|
> 

Thanks for the feedback, i'll change to use choices instead of char values.

alimon

> 
> 
> Michael
> 



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

Re: [yocto] Script being installed under /etc/init.d instead of /usr/lib/systemd folder

[Burton, Ross]

On 9 June 2016 at 02:11, Dey, Megha  wrote:

> However, I do have a script recipe which is currently placed as a bbappend
> to initscripts (meta/recipes-core/initscripts/initscript_..bb) in my custom
> meta layer.
>
>
>
> This script even after shifting to systemd, is being placed in the
> /etc/init.d/ folder, and hence doesn’t run on boot. I want this to be
> placed in the /usr/lib/system.d/ folder instead. How would I be able to do
> this?
>
>
sysv-style init scripts go into /etc/init.d, systemd units do into
/lib/system.d  As this is your append then it is up to you to place the
file in the right location.

If you're installing a traditional init script then /etc/init.d is the
right place for it to be installed, if you're attempting to install a
systemd unit then look at the documentation for the systemd class.

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

Re: [yocto] Mounting USB drives on a "read-only-rootfs" based system

[Fred Ollinger]

There's also bind mounts as an option.


   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

  or by using this fstab entry:

 /olddir /newdir none bind

  After this call the same contents are accessible in two places.  
One can also remount a single  file  (on  a
  single file).


From: yocto-boun...@yoctoproject.org  on behalf 
of Burton, Ross 
Sent: Tuesday, June 14, 2016 7:28 AM
To: Jeffrey D Boyer
Cc: yocto@yoctoproject.org; Christopher Larson
Subject: Re: [yocto] Mounting USB drives on a "read-only-rootfs" based system


On 14 June 2016 at 14:48, Jeffrey D Boyer 
> wrote:
FYI, I'm running 3.14 kernel.  Is this a job for aufs?  If so, how would I go 
about configuring it?

If you want to support arbitrary mounts then it's probably simplest to either 
change /media to be a symlink to /run/media, or put a tmpfs on /media.

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

Re: [yocto] [yocto-autobuilder] [RFC] Add support for generate bitbake error reports

[Aníbal Limón]

On 06/14/2016 10:09 AM, Lock, Joshua G wrote:
> On Thu, 2016-06-09 at 16:23 -0500, Aníbal Limón wrote:
>> Hi folks,
>>
>> Currently we support to send error reports to errors.yoctoproject.org
>> about failing tasks on bitbake using SendErrorReport buildstep but we
>> have a lack of bitbake related errors like exceptions.
>>
>> A bug exist to implement this support into Error report web [1], i'm
>> working on it but for generate bitbake error reports there's a need
>> of
>> some process monitoring the bitbake output in this case the Yocto
>> Autobuilder.
>>
>> This email is for review my current implementation for generate
>> bitbake
>> error reports in the Autobuilder [2] next i'll try to explain how it
>> works.
>>
>> I aadded a BitbakeShellCommand [3] class for use in the buildsteps
>> that
>> executes bitbake the main objective of this class is to have common
>> operations to be made in bitbake commands like create error reports
>> if
>> fails.
>>
>> For create error reports this class add an stdio observer to look at
>> bitbake output and if bitbake fails review the bitbake output for
>> identify if the failure is an non-related task error [4]. If the
>> observer found bitbake error creates an Error report with the
>> information in the master controller.
>>
>> In order to send the bitbake error to Error report web the controller
>> transfer the report to the worker using a new DownloadDirectory
>> implementation that i made [5], the SendErrorReport buildstep works
>> on
>> the worker side so it's easy to transfer the reports from master to
>> worker instead of send it by master.
>>
>> Finally to complete with the job of have the bitbake errors reports
>> the
>> Error report web changes need  (i'm working on it) to be integrated
>> first in order to don't break anything.
>>
>> Please review it and provide me feedback.
> 
> This would've been much easier to review as a series of patches.
> 
> After a quick read via the gitweb the series as a whole looks good.
> 
> A couple of review comments:
> 
> In a04b41d37c29191318386455d8d958ff815a3a10 "lib/buildsteps.py: Add
> BitbakeLogLineObserver for BitbakeShellCommands." you have a comment
> 
> "discard line that are not errors and line that is recipe task errors"
> 
> but the lines are not actually discarded, afaict  from a cursory read
> through they aren't used in the rest of the series
> unless errors['bitbake'] == True? 
> 
> Could we move the error['log'].append() to after the if statement which
> checks whether this is a bitbake error?

Yes and i'll update the commit message to be more consistent.

> 
> Minor nit, in caf472bc696053227825c5a102feef3e17574ba2 "lib/buildsteps:
> BitbakeShellCommand add support for create error reports"
> in get_error_report_bitbake_dir() you use both " and ' for strings.
> 
> Same in 40279597615c49bc4f4f067cbab937584b626671

I'll fix the typos for only use "".

alimon

> 
> Regards,
> 
> Joshua
> 
>>
>> Cheers,
>>  alimon
>>
>> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7583
>> [2]
>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/log/?h=co
>> ntrib/alimon/devel
>> [3]
>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/tree/lib/
>> python2.7/site-
>> packages/autobuilder/lib/buildsteps.py?h=contrib/alimon/devel#n92
>> [4]
>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/tree/lib/
>> python2.7/site-
>> packages/autobuilder/lib/buildsteps.py?h=contrib/alimon/devel#n53
>> [5]
>> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/commit/?h
>> =contrib/alimon/devel=4022920bb0e56d1eef3dfe7c5e9b4699f801cdf1



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

Re: [yocto] Script being installed under /etc/init.d instead of /usr/lib/systemd folder

[piotr.lewicki]

Take a look at example from my some-recipe.bb
:

inherit systemd

SYSTEMD_SERVICE_${PN} = "some-recipe.service"

do_install_append () {
install -d ${D}${systemd_unitdir}/system
install -m 0644 ${S}/configs/some-recipe.service 
${D}${systemd_unitdir}/system

}

First in your recipe inherit from "systemd".
Then install your systemd service file in 
"${D}${systemd_unitdir}/system" (there is also a variable for this 
directory, I think it's ${systemd_system_unitdir} or something similar).

Remember to create a directory before placing a file there.

In the last step use "SYSTEMD_SERVICE_${PN}" where you specify systemd 
services that should be run.


I hope that helps..

Best regards,
Piotr Lewicki


On 09.06.2016 03:11, Dey, Megha wrote:


Hi,

I am trying to use the systemd init system from the existing system. I 
have added the following to my conf file:


DISTRO_FEATURES_append = " systemd"

VIRTUAL-RUNTIME_init_manager = "systemd"

VIRTUAL-RUNTIME_initscripts = ""

DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"

I have also added the ‘systemd’ binary to the INSTALL_APPEND.

When I boot the resulting image, I do see systemd up and running and I 
am able to start and stop services.


However, I do have a script recipe which is currently placed as a 
bbappend to initscripts 
(meta/recipes-core/initscripts/initscript_..bb) in my custom meta layer.


This script even after shifting to systemd, is being placed in the 
/etc/init.d/ folder, and hence doesn’t run on boot. I want this to be 
placed in the /usr/lib/system.d/ folder instead. How would I be able 
to do this?


Is it because this script is an append to initscripts, it by default 
gets installed under /etc/init.d? If so, where should I place the recipe?


Thanks,

Megha





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

Re: [yocto] [yocto-autobuilder] [RFC] Add support for generate bitbake error reports

[Joshua G Lock]

(Resent including the list, apologies for those receiving it again)

On Thu, 2016-06-09 at 16:23 -0500, Aníbal Limón wrote:
> Hi folks,
> 
> Currently we support to send error reports to errors.yoctoproject.org
> about failing tasks on bitbake using SendErrorReport buildstep but we
> have a lack of bitbake related errors like exceptions.
> 
> A bug exist to implement this support into Error report web [1], i'm
> working on it but for generate bitbake error reports there's a need
> of
> some process monitoring the bitbake output in this case the Yocto
> Autobuilder.
> 
> This email is for review my current implementation for generate
> bitbake
> error reports in the Autobuilder [2] next i'll try to explain how it
> works.
> 
> I aadded a BitbakeShellCommand [3] class for use in the buildsteps
> that
> executes bitbake the main objective of this class is to have common
> operations to be made in bitbake commands like create error reports
> if
> fails.
> 
> For create error reports this class add an stdio observer to look at
> bitbake output and if bitbake fails review the bitbake output for
> identify if the failure is an non-related task error [4]. If the
> observer found bitbake error creates an Error report with the
> information in the master controller.
> 
> In order to send the bitbake error to Error report web the controller
> transfer the report to the worker using a new DownloadDirectory
> implementation that i made [5], the SendErrorReport buildstep works
> on
> the worker side so it's easy to transfer the reports from master to
> worker instead of send it by master.
> 
> Finally to complete with the job of have the bitbake errors reports
> the
> Error report web changes need  (i'm working on it) to be integrated
> first in order to don't break anything.
> 
> Please review it and provide me feedback.

This would've been much easier to review as a series of patches.

After a quick read via the gitweb the series as a whole looks good.

A couple of review comments:

In a04b41d37c29191318386455d8d958ff815a3a10 "lib/buildsteps.py: Add
BitbakeLogLineObserver for BitbakeShellCommands." you have a comment

"discard line that are not errors and line that is recipe task errors"

but the lines are not actually discarded, afaict  from a cursory read
through they aren't used in the rest of the series
unless errors['bitbake'] == True? 

Could we move the error['log'].append() to after the if statement which
checks whether this is a bitbake error?

Minor nit, in caf472bc696053227825c5a102feef3e17574ba2 "lib/buildsteps:
BitbakeShellCommand add support for create error reports"
in get_error_report_bitbake_dir() you use both " and ' for strings.

Same in 40279597615c49bc4f4f067cbab937584b626671

Regards,

Joshua

> 
> Cheers,
>   alimon
> 
> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7583
> [2]
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/log/?h=co
> ntrib/alimon/devel
> [3]
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/tree/lib/
> python2.7/site-
> packages/autobuilder/lib/buildsteps.py?h=contrib/alimon/devel#n92
> [4]
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/tree/lib/
> python2.7/site-
> packages/autobuilder/lib/buildsteps.py?h=contrib/alimon/devel#n53
> [5]
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/commit/?h
> =contrib/alimon/devel=4022920bb0e56d1eef3dfe7c5e9b4699f801cdf1
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] resolvconf nameserver

[Rajasekaran, Monica]

Yes, I tried that already.

Thanks,
Monica

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Monday, June 13, 2016 4:58 PM
To: Rajasekaran, Monica 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] resolvconf nameserver


On 13 June 2016 at 22:47, Rajasekaran, Monica 
> 
wrote:
I thought it would be the usual method as in other linux versions such as 
Ubuntu. But there is no /etc/resolv.conf file.

Did you try just creating a /etc/resolv.conf with the nameserver entries you 
want?

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

Re: [yocto] Mounting USB drives on a "read-only-rootfs" based system

[Burton, Ross]

On 14 June 2016 at 14:48, Jeffrey D Boyer  wrote:

> FYI, I'm running 3.14 kernel.  Is this a job for aufs?  If so, how would I
> go about configuring it?
>

If you want to support arbitrary mounts then it's probably simplest to
either change /media to be a symlink to /run/media, or put a tmpfs on
/media.

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

Re: [yocto] Mounting USB drives on a "read-only-rootfs" based system

[Jeffrey D Boyer]

Sorry, /media is not a symlink and there is no /run/media link or directory 
present on my running system.  When I insert an SD card, for example, I get a 
bit of text on the debug serial port that a card has been detected, but I don't 
see a mount point anywhere after that.

root@mySys:/# mmc1: new high speed SDHC card at address 1234
mmcblk1: mmc1:1234 SA04G 3.63 GiB
 mmcblk1: p1

It should be noted that if I exclude the " read-only-rootfs" option in the bb 
script, a normal read/write kernel image is produced and the action of 
inserting an SD card under those conditions will automatically produce a mount 
point at /media/mmcblk1p1

FYI, I'm running 3.14 kernel.  Is this a job for aufs?  If so, how would I go 
about configuring it?


-Original Message-
From: Mike Looijmans [mailto:mike.looijm...@topic.nl] 
Sent: Tuesday, June 14, 2016 9:18 AM
To: Christopher Larson ; Jeffrey D Boyer 

Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Mounting USB drives on a "read-only-rootfs" based system

Yup, even mdev based images do that with current OE.

I'd expect "/media" to symlink to "run/media" on most devices (regardless 
whether the rootfs is read-only or not). Check if that's the case on your 
system.

On 14-06-16 00:01, Christopher Larson wrote:
> Afaik usb storage is already automounted by udev on /run/media/, so 
> there's no need to use /media for that purpose.
>
> On Mon, Jun 13, 2016 at 2:22 PM, Jeffrey D Boyer 
> > wrote:
>
> Hello,
>
> __ __
>
> New to the list here, so I’m sorry if this question has been asked before,
> but I couldn’t find a direct answer to it. 
>
> __ __
>
> I have a yocto image that was built using the following bb script line:
> IMAGE_FEATURES += " read-only-rootfs". 
>
> __ __
>
> As this image eventually resides on a static flash device, it must be
> read-only.  However, the system hardware supports removable media (SD card
> and USB drives), and I’d like to be able to mount and write to those
> removable drives / partitions for data logging purposes.  What needs to be
> done in order to make the /media directory auto-mountable when a
> “read-only” image is specified by the build script?
>
> __ __
>
> Thanks.
>
> __ __
>
>
> --
> 

Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
>
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior 
> Software Engineer, Mentor Graphics
>
>

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

Re: [yocto] [[PATCH][error-report-web] 5/8] Post/models.py: Build model add support for Error type.

[Michael Wood]

On 14/06/16 00:32, Aníbal Limón wrote:

In order to support other errors not only Recipe ones adds
a ERROR_TYPE field to the Build model defaults to "Recipe".

Add a class for store BuildErrorType currently supported
Recipe, Core, Bitbake selftest and OE selftest.

[YOCTO #7583]

Signed-off-by: Aníbal Limón 
---
  Post/migrations/0005_build_error_type.py | 19 +++
  Post/models.py   |  7 +++
  2 files changed, 26 insertions(+)
  create mode 100644 Post/migrations/0005_build_error_type.py

diff --git a/Post/migrations/0005_build_error_type.py 
b/Post/migrations/0005_build_error_type.py
new file mode 100644
index 000..96cdf8c
--- /dev/null
+++ b/Post/migrations/0005_build_error_type.py
@@ -0,0 +1,19 @@
+# -*- coding: utf-8 -*-
+from __future__ import unicode_literals
+
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+dependencies = [
+('Post', '0004_auto_20160530_1126'),
+]
+
+operations = [
+migrations.AddField(
+model_name='build',
+name='ERROR_TYPE',
+field=models.CharField(default=b'Recipe', max_length=64),
+),
+]
diff --git a/Post/models.py b/Post/models.py
index 84f8abf..f8d9916 100644
--- a/Post/models.py
+++ b/Post/models.py
@@ -11,6 +11,12 @@ from datetime import datetime
  
  import Levenshtein
  
+class BuildErrorType(object):

+RECIPE = "Recipe"
+BITBAKE_CORE = "Core"
+BITBAKE_SELFTEST = "Bitbake selftest"
+OE_SELFTEST = "OE selftest"
+
  # Create your models here.
  class Build(models.Model):
  DATE = models.DateTimeField('Submit date', blank=True, null=True)
@@ -25,6 +31,7 @@ class Build(models.Model):
  NAME = models.CharField(max_length=50)
  EMAIL = models.CharField(max_length=50)
  LINK_BACK = models.TextField(max_length=300, blank=True, null=True)
+ERROR_TYPE = models.CharField(max_length=64, default=BuildErrorType.RECIPE)
  
  class BuildFailure(models.Model):

  TASK = models.CharField(max_length=1024)


Thanks for the patches.

Ideally we wouldn't use a char field here as if the type string ever 
changed the database could end up with multiple versions of the type 
strings depending on when the type was saved, it would be possible to 
handle that with migrations but it would be pretty messy. It also allows 
any arbitrary chars which we probably don't want if it's something we're 
going to be filtering on.  Here is an example from Toaster on how it can 
be done with the choices option and an enum style.


|OUTCOME_NA = -1 OUTCOME_SUCCESS = 0 OUTCOME_COVERED = 1 OUTCOME_CACHED = 
2 OUTCOME_PREBUILT = 3 OUTCOME_FAILED = 4 OUTCOME_EMPTY = 5 TASK_OUTCOME 
= ( (OUTCOME_NA, 'Not Available'), (OUTCOME_SUCCESS, 'Succeeded'), 
(OUTCOME_COVERED, 'Covered'), (OUTCOME_CACHED, 'Cached'), 
(OUTCOME_PREBUILT, 'Prebuilt'), (OUTCOME_FAILED, 'Failed'), 
(OUTCOME_EMPTY, 'Empty'), ) ||outcome = models.IntegerField(choices=TASK_OUTCOME, default=OUTCOME_NA)|




Michael

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

Re: [yocto] Mounting USB drives on a "read-only-rootfs" based system

[Mike Looijmans]

Yup, even mdev based images do that with current OE.

I'd expect "/media" to symlink to "run/media" on most devices (regardless 
whether the rootfs is read-only or not). Check if that's the case on your system.


On 14-06-16 00:01, Christopher Larson wrote:

Afaik usb storage is already automounted by udev on /run/media/, so there's no
need to use /media for that purpose.

On Mon, Jun 13, 2016 at 2:22 PM, Jeffrey D Boyer > wrote:

Hello,

__ __

New to the list here, so I’m sorry if this question has been asked before,
but I couldn’t find a direct answer to it. 

__ __

I have a yocto image that was built using the following bb script line:
IMAGE_FEATURES += " read-only-rootfs". 

__ __

As this image eventually resides on a static flash device, it must be
read-only.  However, the system hardware supports removable media (SD card
and USB drives), and I’d like to be able to mount and write to those
removable drives / partitions for data logging purposes.  What needs to be
done in order to make the /media directory auto-mountable when a
“read-only” image is specified by the build script?

__ __

Thanks.

__ __


--



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





___

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




--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics




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

[yocto] Test Cycle Report for Yocto Project master branch

[Perez Carranza, Jose]

Hi

Here is the status for the test cycle of automated tests on master branch 
commit 6c5d7f1fb276cbe0a461ece6c8f0ca17a478fa8c

Summary :


- Toaster - NameError when trying to search a table due Django, this 
one is blocking around 30% of the execution : 9749 [1]

- Build Appliance : bitbake fails to build image this one is blocking 
50% of the  execution of the component: 9758 [2]

- Failed to extract rootfs by using runqemu-extract-sd: is blocking 
around 11% of the execution of ADT in 2 ditros: 9761 [3]

- Missing smart packages: 9754 duplicated of 9717 [4]

- Failure with Git-Phyton 9742 duplicated of 9716 [5]

- distrodata class don't work with python3: 9744 [6]

- AUH: Make sure that works with python3: 9747 [7]

- Parse logs failed: 9520 [8]

- oe-selftest is not running test cases from meta-yocto-bsp: [9] 9767


[1]-  https://bugzilla.yoctoproject.org/show_bug.cgi?id=9749
[2] - https://bugzilla.yoctoproject.org/show_bug.cgi?id=9758
[3] - https://bugzilla.yoctoproject.org/show_bug.cgi?id=9761
[4] - https://bugzilla.yoctoproject.org/show_bug.cgi?id=9717
[5]-  https://bugzilla.yoctoproject.org/show_bug.cgi?id=9716
[6]- https://bugzilla.yoctoproject.org/show_bug.cgi?id=9744
[7]- https://bugzilla.yoctoproject.org/show_bug.cgi?id=9747
[8]-  https://bugzilla.yoctoproject.org/show_bug.cgi?id=9520
[9]- https://bugzilla.yoctoproject.org/show_bug.cgi?id=9767


The full report can be found here: 
https://wiki.yoctoproject.org/wiki/WW24_-_2016-06-07_-_Automated_Tests_-_Master

Regards,
José

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

Re: [yocto] Customization for nginx

[piotr.lewicki]

This is not an answer to your question but it can be helpful:
You can use a wildcard for version in your bbappend file.
If you rename it to:

nginx_1.9.%.bbappend

this will work for both 1.9.5 and 1.9.14.

For debugging I can give you a hint:
try using "-v" switch for bitbake when baking your nginx recipe- this 
stands for "verbose".


Best regards,
Piotr Lewicki

On 14.06.2016 09:15, Elias Diem wrote:

Hi

With jethro, I used to use the following .bbappend to use
my config for nginx:


FILESEXTRAPATHS_prepend := "${THISDIR}/files:"



My nginx.conf was inside the corresponding files directory.

Since krogoth, which uses nginx 1.9.14, this does not seem to work any 
more. My config file is not used any more. The .bbappend file how has 
the name nginx_1.9.14.bbappend of course.


What could be the reason for this?

Or, alternatively: where can I debug this?




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

[yocto] [Found Error] Re: License problems when switching form RPM to DEB - looking for a easy way to fix it

[S . Jaritz]

Hej

I found the error at the QA check of the debian packages. The deb QA modul 
has problems resolving the links into the 
"sysroots//pkgdata/runtime-resolve". This is because there is a 
lowcase conversation of the recipe name:

p.e.:

"helloMyWorld.bb"

the name of the link is "helloMyWorld"

the QA module is searching for: "hellomyworld"

by renaming the recipe to lowcase letters solves the error. Maybe someone 
can fix it.

Regards!

Stefan Jaritz


ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 176
Telefax: +49 3437 9211 26
E-Mail: s.jar...@esa-grimma.de
Internet: www.esa-grimma.de


Geschäftsführer:
Dipl.-Ing. Jörg Gaitzsch
Jörg Reinker

Sitz der Gesellschaft: Grimma
Ust.-ID: DE 141784437
Amtsgericht: Leipzig, HRB 5159
Steuernummer: 238/108/00755


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
erhalten 
haben, informieren Sie bitte sofort den Absender und löschen Sie diese 
Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser 
Mail 
ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you 
are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is 
strictly 
forbidden.
- Weitergeleitet von Stefan Jaritz/User/ESA-Grimma/DE am 14.06.2016 
11:50 -

Von:Stefan Jaritz/User/ESA-Grimma/DE
An: "Burton, Ross" , 
roman.shaposhni...@globallogic.com
Kopie:  "yocto@yoctoproject.org" 
Datum:  13.06.2016 13:32
Betreff:Antwort: Re: [yocto] License problems when switching form 
RPM to DEB - looking for a easy way to fix it


Hej

I deleted the tmp and rebuild it. But the error stays. I added a licence 
file to the repro and added the

LICENSE="ESA"
LIC_FILES_CHKSUM="files://ESAlicense.txt;md5=.."

What's the connection between the LICENSE and LIC_FILES_CHKSUM field?
How the license manifest is build?

I think the error is releated to the point, that there is possibly no 
LICENSE entry connected to "ESA" or "CLOSED".
Below the error print:
##
ERROR: core-image-minimal-1.0-r0 do_rootfs: Error executing a python 
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure 
was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:license_create_manifest(d)
 0003:
File: '/home/user/myTC/poky/meta/classes/license.bbclass', lineno: 48, 
function: license_create_manifest
 0044:pkg_dic = {}
 0045:for pkg in sorted(image_list_installed_packages(d)):
 0046:pkg_info = os.path.join(d.getVar('PKGDATA_DIR', True),
 0047:'runtime-reverse', pkg)
 *** 0048:pkg_name = os.path.basename(os.readlink(pkg_info))
 0049:
 0050:pkg_dic[pkg_name] = 
oe.packagedata.read_pkgdatafile(pkg_info)
 0051:if not "LICENSE" in pkg_dic[pkg_name].keys():
 0052:pkg_lic_name = "LICENSE_" + pkg_name
Exception: OSError: [Errno 2] No such file or directory: 
'/home/user/myTC/poky/build/tmp/sysroots/sama5d3xek/pkgdata/runtime-reverse/mycontrol'

ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: 
license_create_manifest
ERROR: Logfile of failure stored in: 
/home/user/myTC/poky/build/tmp/work/sama5d3xek-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.22140
ERROR: Task 9 
(/home/user/myTC/poky/meta/recipes-core/images/core-image-minimal.bb, 
do_rootfs) failed with exit code '1'
##

Regards!

Stefan Jaritz



ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 176
Telefax: +49 3437 9211 26
E-Mail: s.jar...@esa-grimma.de
Internet: www.esa-grimma.de


Geschäftsführer:
Dipl.-Ing. Jörg Gaitzsch
Jörg Reinker

Sitz der Gesellschaft: Grimma
Ust.-ID: DE 141784437
Amtsgericht: Leipzig, HRB 5159
Steuernummer: 238/108/00755


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
erhalten 
haben, informieren Sie bitte sofort den Absender und löschen Sie diese 
Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser 
Mail 
ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you 
are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is 
strictly 
forbidden.



Von:"Burton, Ross" 
An: 

[yocto] Customization for nginx

[Elias Diem]

Hi

With jethro, I used to use the following .bbappend to use
my config for nginx:


FILESEXTRAPATHS_prepend := "${THISDIR}/files:"



My nginx.conf was inside the corresponding files directory.

Since krogoth, which uses nginx 1.9.14, this does not seem 
to work any more. My config file is not used any more. The 
.bbappend file how has the name nginx_1.9.14.bbappend of 
course.


What could be the reason for this?

Or, alternatively: where can I debug this?


--
Greetings
Elias


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

Re: [yocto] Mounting USB drives on a "read-only-rootfs" based system

[Richard Leitner]

Hi,
you can adjust the mount behaviour for example in your udev mount script
(if you use udev).

If you have a fixed name/mountpoint for your media you can pre-create
that folder (for example /media/data-logging) and let udev's mount.sh
mount media which matches your criteria to that path.

kind regards,
richard
On 06/13/2016 11:22 PM, Jeffrey D Boyer wrote:
> Hello,
> 
>  
> 
> New to the list here, so I’m sorry if this question has been asked
> before, but I couldn’t find a direct answer to it. 
> 
>  
> 
> I have a yocto image that was built using the following bb script line:
> IMAGE_FEATURES += " read-only-rootfs". 
> 
>  
> 
> As this image eventually resides on a static flash device, it must be
> read-only.  However, the system hardware supports removable media (SD
> card and USB drives), and I’d like to be able to mount and write to
> those removable drives / partitions for data logging purposes.  What
> needs to be done in order to make the /media directory auto-mountable
> when a “read-only” image is specified by the build script?
> 
>  
> 
> Thanks.
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PULL REQUEST] Watchdog parenting fix for linux-yocto-4.1

[Yong, Jonathan]

On 06/14/2016 09:59, Yong, Jonathan wrote:

This series of 11 patches from Linus's tree fixes the parenting of
watchdog devices. To do that, a lot of OMAP watchdog fixes are pulled in
as dependencies.

Adds Conexant Digicolor CX9 and STMicroelectronics LPC Watchdog.

https://github.com/jyong2/yocto-backports.git
branch: for-linux-yocto-4.1



These 2 branches should also go into linux-yocto-4.1 standard/base:
for-linux-yocto-4.1-core  (driver core backports from Linus's)
for-linux-yocto-4.1-power (CPU idle/powercap backports from Linus's)

Thanks!

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