date:20161006

Re: [yocto] [[yocto-autobuilder][PATCHv3]] Build sets to test new OS distribution in autobuilder

2016-10-06 Thread Beth 'pidge' Flanagan

On Wed, 2016-10-05 at 15:54 -0500, Monserrat Sedeno wrote:
> As part of the process to set new OS distribution as supported on
> Yoctoc Project
> a new patch was created with the list of build sets that should be
> executed.
> 
> Detailed information:
> https://wiki.yoctoproject.org/wiki/Distro_Testing_Plan#Execute_Build_
> Sets
> 
> Fixes [YOCTO #9905]
> 
> Note:In order to add a new distro as supported all the build sets
> should be PASS

Sorry for the review delay here.

autobuilder-qa isn't really the right spot for this.

What I would suggest is:

1. A new directory called buildset-config.distro-qa
2. All targets needed for that buildset should be in there. If they
should track the buildsets in buildset-config.controller, make symlinks
so we don't need to maintain two sets of buildsets.

Everything in a buildset-config* should be self-contained and
buildable.

-b

> 
> Signed-off-by: Monserrat Sedeno 
> ---
>  .../nightly-qa-distro.conf | 44
> ++
>  1 file changed, 44 insertions(+)
>  create mode 100644 buildset-config.autobuilder-qa/nightly-qa-
> distro.conf
> 
> diff --git a/buildset-config.autobuilder-qa/nightly-qa-distro.conf
> b/buildset-config.autobuilder-qa/nightly-qa-distro.conf
> new file mode 100644
> index 000..6c02a91
> --- /dev/null
> +++ b/buildset-config.autobuilder-qa/nightly-qa-distro.conf
> @@ -0,0 +1,44 @@
> +[nightly-qa-distro]
> +builders: 'example-worker'
> +repos: [{'poky':
> +{'repourl':'git://git.yoctoproject.org/poky',
> + 'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-
> bsp', 'yocto':'meta-yocto', 'poky':'meta-poky'},
> + 'branch':'master'}},
> +{'meta-qt4':
> +{'repourl':'git://git.yoctoproject.org/meta-qt4',
> + 'branch':'master'}},
> +{'meta-qt3':
> +{'repourl':'git://git.yoctoproject.org/meta-qt3',
> + 'branch':'master'}}]
> +props: [{'fp_date':{'prop_type':'StringParameter',
> +   'size': 20,
> +   'name': 'fp_date',
> +   'label':'Full Pass date:'}}]
> +steps: [{'SetDest':{}},
> +{'CheckOutLayers': {}},
> +{'RunPreamble': {}},
> +{'TriggerBuilds': {'schedulerName': 'dist-build', 
> +    'waitForFinish': 'True',
> +   'schedulerNames': {
> +     'nightly-oe-selftest': {},
> +     'nightly-rpm': {},
> +     'nightly-deb': {},
> +     'nightly-ipk': {},
> +     'nightly-world': {}, 
> +     'nightly-arm': {}, 
> +     'nightly-mips': {},
> +     'nightly-wic':{},
> +     'nightly-multilib': {}, 
> +     'nightly-x86-64': {}, 
> +     'nightly-x86-64-lsb': {},
> +     'nightly-x86': {},
> +     'poky-tiny': {}, 
> +     'nightly-qa-systemd': {},
> +     'nightly-qa-extras': {}, 
> +     'nightly-qa-targetbuilds': {},
> + 'nightly-qa-skeleton': {},
> +     'nightly-qa-logrotate': {}, 
> +     'nightly-qa-pam': {},
> + 'buildtools': {}},
> +   'schedulerNames_nowait': {}}},]
> +
> -- 
> 2.7.4
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: remove redundant IMAGEDATESTAMP

2016-10-06 Thread Jonathan Liu

On 6 October 2016 at 02:00, Trevor Woerner  wrote:
> On Wed 2016-10-05 @ 11:01:15 AM, Jonathan Liu wrote:
>> See if the following helps:
>> bitbake -c cleanall core-image-minimal && bitbake core-image-minimal
>
> Odd. I had started this email to say that this wasn't working (since this is
> exactly what I had tried a couple times over the last several days) and I find
> I can't reproduce the issue.
>
> I was able to reproduce the issue a couple times earlier today, but to write
> this email I updates all repositories. There was no change (since yesterday)
> to meta-raspberrypi but openembedded-core had updates, and some of those
> updates required an update to bitbake. Now everything seems to work.
>
> I'll keep an eye on it ;-)
>
> Thanks and best regards,
> Trevor

I ran into this issue again after wiping my build directory.
I suspect it may be the kernel version checking logic causing the issue.

For a clean build directory:
$ bitbake -e core-image-minimal | grep ^RPI_KERNEL_VERSION
RPI_KERNEL_VERSION="None"

For a used build directory:
$ bitbake -e core-image-minimal | grep ^RPI_KERNEL_VERSION
RPI_KERNEL_VERSION="4.4.16"

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

[yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: Remove redundant RPI_KERNEL_VERSION

2016-10-06 Thread Jonathan Liu

The value of the RPI_KERNEL_VERSION can change between None and the
kernel version which can result in taskhash mismatch errors while
building images.

The taskhash mismatch errors can be reproduced using:
bitbake -c cleansstate virtual/kernel core-image-minimal && bitbake 
core-image-minimal

The get_dts() and split_overlays() functions are modified so that the
kernel version argument is optional. If the version is not supplied to
these functions, they will fallback to the Python equivalent of the
expression used for RPI_KERNEL_VERSION.

Signed-off-by: Jonathan Liu 
---
 classes/linux-raspberrypi-base.bbclass | 4 ++--
 classes/sdcard_image-rpi.bbclass   | 8 +++-
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/classes/linux-raspberrypi-base.bbclass 
b/classes/linux-raspberrypi-base.bbclass
index 930fc44..3a6e33d 100644
--- a/classes/linux-raspberrypi-base.bbclass
+++ b/classes/linux-raspberrypi-base.bbclass
@@ -1,6 +1,6 @@
 inherit linux-kernel-base
 
-def get_dts(d, ver):
+def get_dts(d, ver=None):
 import re
 
 staging_dir = d.getVar("STAGING_KERNEL_BUILDDIR", True)
@@ -32,7 +32,7 @@ def get_dts(d, ver):
 return dts
 
 
-def split_overlays(d, ver, out):
+def split_overlays(d, out, ver=None):
 dts = get_dts(d, ver)
 if out:
 overlays = oe.utils.str_filter_out('\S+\-overlay\.dtb$', dts, d)
diff --git a/classes/sdcard_image-rpi.bbclass b/classes/sdcard_image-rpi.bbclass
index 2f0daee..0487ef1 100644
--- a/classes/sdcard_image-rpi.bbclass
+++ b/classes/sdcard_image-rpi.bbclass
@@ -71,8 +71,6 @@ SDIMG = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.rpi-sdimg"
 # Additional files and/or directories to be copied into the vfat partition 
from the IMAGE_ROOTFS.
 FATPAYLOAD ?= ""
 
-RPI_KERNEL_VERSION := 
"${@get_kernelversion_file('${STAGING_KERNEL_BUILDDIR}')}"
-
 IMAGE_CMD_rpi-sdimg () {
 
# Align partitions
@@ -83,7 +81,7 @@ IMAGE_CMD_rpi-sdimg () {
echo "Creating filesystem with Boot partition ${BOOT_SPACE_ALIGNED} KiB 
and RootFS $ROOTFS_SIZE KiB"
 
# Check if we are building with device tree support
-   DTS="${@get_dts(d, '${RPI_KERNEL_VERSION}')}"
+   DTS="${@get_dts(d)}"
 
# Initialize sdcard image file
dd if=/dev/zero of=${SDIMG} bs=1024 count=0 seek=${SDIMG_SIZE}
@@ -104,8 +102,8 @@ IMAGE_CMD_rpi-sdimg () {
mcopy -i ${WORKDIR}/boot.img -s ${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/* 
::/
if test -n "${DTS}"; then
# Device Tree Overlays are assumed to be suffixed by 
'-overlay.dtb' (4.1.x) or by '.dtbo' (4.4.9+) string and will be put in a 
dedicated folder
-   DT_OVERLAYS="${@split_overlays(d, '${RPI_KERNEL_VERSION}', 0)}"
-   DT_ROOT="${@split_overlays(d, '${RPI_KERNEL_VERSION}', 1)}"
+   DT_OVERLAYS="${@split_overlays(d, 0)}"
+   DT_ROOT="${@split_overlays(d, 1)}"
 
# Copy board device trees to root folder
for DTB in ${DT_ROOT}; do
-- 
2.10.0

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

[yocto] [x32 ABI] Bit size mismatch in grub-efi

2016-10-06 Thread Michel D'HOOGE

Hi,

I'd like to give the x32 ABI a try, so I followed the steps in section 4.4 of 
the reference manual.

First, I tried the core-image-sato recipe, and then switched to 
core-image-minimal because it is faster to recompile from scratch… However I 
assume both should work since Sato is explicitly referred to in the manual, and 
minimal should always work! And for completeness, I am on the master branch of 
poky.

So, this doesn't work and I get many lines like the following ones from 
grub-efi:

ERROR: grub-efi-2.00-r3 do_package_qa: QA Issue: Bit size did not match (32 to 
64) grub-efi on 
/work/x86_64_x32-poky-linux-gnux32/grub-efi/2.00-r3/packages-split/grub-efi/usr/libx32/grub/x86_64-efi/kernel.img
Bit size did not match (32 to 64) grub-efi on 
/work/x86_64_x32-poky-linux-gnux32/grub-efi/2.00-r3/packages-split/grub-efi/usr/libx32/grub/x86_64-efi/trig.mod
Bit size did not match (32 to 64) grub-efi on 
/work/x86_64_x32-poky-linux-gnux32/grub-efi/2.00-r3/packages-split/grub-efi/usr/libx32/grub/x86_64-efi/cs5536.mod
Bit size did not match (32 to 64) grub-efi on 
/work/x86_64_x32-poky-linux-gnux32/grub-efi/2.00-r3/packages-split/grub-efi/usr/libx32/grub/x86_64-efi/usb.mod
Bit size did not match (32 to 64) grub-efi on 
/work/x86_64_x32-poky-linux-gnux32/grub-efi/2.00-r3/packages-split/grub-efi/usr/libx32/grub/x86_64-efi/usbserial_common.mod

And then, it fails:
ERROR: grub-efi-2.00-r3 do_package_qa: QA run found fatal errors. Please 
consider fixing them.
ERROR: grub-efi-2.00-r3 do_package_qa: Function failed: do_package_qa
ERROR: Logfile of failure stored in: 
/mnt/Yocto/Fabric-x32/build/tmp/work/x86_64_x32-poky-linux-gnux32/grub-efi/2.00-r3/temp/log.do_package_qa.11229
ERROR: Task 
(/mnt/Yocto/Fabric-x32/sources/poky/meta/recipes-bsp/grub/grub-efi_2.00.bb:do_package_qa)
 failed with exit code '1'


AFAIK, the image won't use EFI. And I guess this package is only required by 
the native part "by default".

What is the proper solution to bypass these errors?

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

[yocto] PSPLASH behavior during shutdown

2016-10-06 Thread Mark Junghanns

Hi there,
I have a question concerning Psplash's behavior during shutdown. My image is 
using xfce4 and I'm using psplash to display a logo during startup. This is 
working as expected. My problem starts when I'm shutting down the session. The 
X-server stops and the console becomes visible (displaying the usual stuff that 
is shown during shutting down), until the splash screen appears - which is not 
very reliable either. Could somebody give me a hint on where to start solving 
this?

Many thanks in advance,
Mark
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: Remove redundant RPI_KERNEL_VERSION

2016-10-06 Thread Andreas Müller

On Thu, Oct 6, 2016 at 2:20 PM, Jonathan Liu  wrote:
> The value of the RPI_KERNEL_VERSION can change between None and the
> kernel version which can result in taskhash mismatch errors while
> building images.
>
> The taskhash mismatch errors can be reproduced using:
> bitbake -c cleansstate virtual/kernel core-image-minimal && bitbake 
> core-image-minimal
>
> The get_dts() and split_overlays() functions are modified so that the
> kernel version argument is optional. If the version is not supplied to
> these functions, they will fallback to the Python equivalent of the
> expression used for RPI_KERNEL_VERSION.
>
> Signed-off-by: Jonathan Liu 
> ---
>  classes/linux-raspberrypi-base.bbclass | 4 ++--
>  classes/sdcard_image-rpi.bbclass   | 8 +++-
>  2 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/classes/linux-raspberrypi-base.bbclass 
> b/classes/linux-raspberrypi-base.bbclass
> index 930fc44..3a6e33d 100644
> --- a/classes/linux-raspberrypi-base.bbclass
> +++ b/classes/linux-raspberrypi-base.bbclass
> @@ -1,6 +1,6 @@
>  inherit linux-kernel-base
>
> -def get_dts(d, ver):
> +def get_dts(d, ver=None):
>  import re
>
>  staging_dir = d.getVar("STAGING_KERNEL_BUILDDIR", True)
> @@ -32,7 +32,7 @@ def get_dts(d, ver):
>  return dts
>
>
> -def split_overlays(d, ver, out):
> +def split_overlays(d, out, ver=None):
>  dts = get_dts(d, ver)
>  if out:
>  overlays = oe.utils.str_filter_out('\S+\-overlay\.dtb$', dts, d)
> diff --git a/classes/sdcard_image-rpi.bbclass 
> b/classes/sdcard_image-rpi.bbclass
> index 2f0daee..0487ef1 100644
> --- a/classes/sdcard_image-rpi.bbclass
> +++ b/classes/sdcard_image-rpi.bbclass
> @@ -71,8 +71,6 @@ SDIMG = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.rpi-sdimg"
>  # Additional files and/or directories to be copied into the vfat partition 
> from the IMAGE_ROOTFS.
>  FATPAYLOAD ?= ""
>
> -RPI_KERNEL_VERSION := 
> "${@get_kernelversion_file('${STAGING_KERNEL_BUILDDIR}')}"
> -
>  IMAGE_CMD_rpi-sdimg () {
>
> # Align partitions
> @@ -83,7 +81,7 @@ IMAGE_CMD_rpi-sdimg () {
> echo "Creating filesystem with Boot partition ${BOOT_SPACE_ALIGNED} 
> KiB and RootFS $ROOTFS_SIZE KiB"
>
> # Check if we are building with device tree support
> -   DTS="${@get_dts(d, '${RPI_KERNEL_VERSION}')}"
> +   DTS="${@get_dts(d)}"
>
> # Initialize sdcard image file
> dd if=/dev/zero of=${SDIMG} bs=1024 count=0 seek=${SDIMG_SIZE}
> @@ -104,8 +102,8 @@ IMAGE_CMD_rpi-sdimg () {
> mcopy -i ${WORKDIR}/boot.img -s 
> ${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/* ::/
> if test -n "${DTS}"; then
> # Device Tree Overlays are assumed to be suffixed by 
> '-overlay.dtb' (4.1.x) or by '.dtbo' (4.4.9+) string and will be put in a 
> dedicated folder
> -   DT_OVERLAYS="${@split_overlays(d, '${RPI_KERNEL_VERSION}', 
> 0)}"
> -   DT_ROOT="${@split_overlays(d, '${RPI_KERNEL_VERSION}', 1)}"
> +   DT_OVERLAYS="${@split_overlays(d, 0)}"
> +   DT_ROOT="${@split_overlays(d, 1)}"
>
> # Copy board device trees to root folder
> for DTB in ${DT_ROOT}; do
> --
> 2.10.0
>
Yes this makes sense - thanks.

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

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: Remove redundant RPI_KERNEL_VERSION

2016-10-06 Thread Khem Raj


> On Oct 6, 2016, at 5:20 AM, Jonathan Liu  wrote:
> 
> The value of the RPI_KERNEL_VERSION can change between None and the
> kernel version which can result in taskhash mismatch errors while
> building images.
> 
> The taskhash mismatch errors can be reproduced using:
> bitbake -c cleansstate virtual/kernel core-image-minimal && bitbake 
> core-image-minimal
> 
> The get_dts() and split_overlays() functions are modified so that the
> kernel version argument is optional. If the version is not supplied to
> these functions, they will fallback to the Python equivalent of the
> expression used for RPI_KERNEL_VERSION.

I was able to see this error and was reaching same conclusions. I have staged 
this patch on
kraj/master and will test it out

> 
> Signed-off-by: Jonathan Liu 
> ---
> classes/linux-raspberrypi-base.bbclass | 4 ++--
> classes/sdcard_image-rpi.bbclass   | 8 +++-
> 2 files changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/classes/linux-raspberrypi-base.bbclass 
> b/classes/linux-raspberrypi-base.bbclass
> index 930fc44..3a6e33d 100644
> --- a/classes/linux-raspberrypi-base.bbclass
> +++ b/classes/linux-raspberrypi-base.bbclass
> @@ -1,6 +1,6 @@
> inherit linux-kernel-base
> 
> -def get_dts(d, ver):
> +def get_dts(d, ver=None):
> import re
> 
> staging_dir = d.getVar("STAGING_KERNEL_BUILDDIR", True)
> @@ -32,7 +32,7 @@ def get_dts(d, ver):
> return dts
> 
> 
> -def split_overlays(d, ver, out):
> +def split_overlays(d, out, ver=None):
> dts = get_dts(d, ver)
> if out:
> overlays = oe.utils.str_filter_out('\S+\-overlay\.dtb$', dts, d)
> diff --git a/classes/sdcard_image-rpi.bbclass 
> b/classes/sdcard_image-rpi.bbclass
> index 2f0daee..0487ef1 100644
> --- a/classes/sdcard_image-rpi.bbclass
> +++ b/classes/sdcard_image-rpi.bbclass
> @@ -71,8 +71,6 @@ SDIMG = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.rpi-sdimg"
> # Additional files and/or directories to be copied into the vfat partition 
> from the IMAGE_ROOTFS.
> FATPAYLOAD ?= ""
> 
> -RPI_KERNEL_VERSION := 
> "${@get_kernelversion_file('${STAGING_KERNEL_BUILDDIR}')}"
> -
> IMAGE_CMD_rpi-sdimg () {
> 
>   # Align partitions
> @@ -83,7 +81,7 @@ IMAGE_CMD_rpi-sdimg () {
>   echo "Creating filesystem with Boot partition ${BOOT_SPACE_ALIGNED} KiB 
> and RootFS $ROOTFS_SIZE KiB"
> 
>   # Check if we are building with device tree support
> - DTS="${@get_dts(d, '${RPI_KERNEL_VERSION}')}"
> + DTS="${@get_dts(d)}"
> 
>   # Initialize sdcard image file
>   dd if=/dev/zero of=${SDIMG} bs=1024 count=0 seek=${SDIMG_SIZE}
> @@ -104,8 +102,8 @@ IMAGE_CMD_rpi-sdimg () {
>   mcopy -i ${WORKDIR}/boot.img -s ${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/* 
> ::/
>   if test -n "${DTS}"; then
>   # Device Tree Overlays are assumed to be suffixed by 
> '-overlay.dtb' (4.1.x) or by '.dtbo' (4.4.9+) string and will be put in a 
> dedicated folder
> - DT_OVERLAYS="${@split_overlays(d, '${RPI_KERNEL_VERSION}', 0)}"
> - DT_ROOT="${@split_overlays(d, '${RPI_KERNEL_VERSION}', 1)}"
> + DT_OVERLAYS="${@split_overlays(d, 0)}"
> + DT_ROOT="${@split_overlays(d, 1)}"
> 
>   # Copy board device trees to root folder
>   for DTB in ${DT_ROOT}; do
> --
> 2.10.0
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] which meta-intel woudl build a kernel 4.8

2016-10-06 Thread Dominig ar Foll (Intel Open Source)

Hello,

I was happily under 'jethro' until now but I need to build a kernel 4.8
fir Intel HW to get access to some new features.

I can see that the 'master' branch bump to 4.8 but unfortunately come
with the following errors :

ERROR: No recipes available for:
 
/home/dominig/AGL/meta-intel/common/recipes-kernel/linux/linux-yocto-tiny_4.8.bbappend
 
/home/dominig/AGL/meta-intel/common/recipes-kernel/linux/linux-yocto_4.8.bbappend

Would someone have an idea how I could get a 4.8 working meta-intel ?

Thanks in advance

-- 

Dominig ar Foll
Senior Software Architect
Intel Open Source Technology Centre

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

Re: [yocto] which meta-intel woudl build a kernel 4.8

2016-10-06 Thread Khem Raj

Use poky or oe-core master with master of meta-intel is best shot

On Oct 6, 2016 11:16 AM, "Dominig ar Foll (Intel Open Source)" <
dominig.arf...@fridu.net> wrote:

> Hello,
>
> I was happily under 'jethro' until now but I need to build a kernel 4.8
> fir Intel HW to get access to some new features.
>
> I can see that the 'master' branch bump to 4.8 but unfortunately come
> with the following errors :
>
> ERROR: No recipes available for:
>
> /home/dominig/AGL/meta-intel/common/recipes-kernel/linux/
> linux-yocto-tiny_4.8.bbappend
>
> /home/dominig/AGL/meta-intel/common/recipes-kernel/linux/
> linux-yocto_4.8.bbappend
>
> Would someone have an idea how I could get a 4.8 working meta-intel ?
>
> Thanks in advance
>
> --
>
> Dominig ar Foll
> Senior Software Architect
> Intel Open Source Technology Centre
>
> --
> ___
> 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] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

2016-10-06 Thread Dinh Nguyen (dinhn)


>> yes thats normal when package is re-used from sstate-cache

Many thanks Khem. Got it, so the IPK packages were built early is OK. 
I did a clean all and redo the bitbake, all packages, images were rebuilt.

Thanks again,
  —Dinh 


>
>> On Oct 5, 2016, at 11:43 AM, Dinh Nguyen (dinhn)  wrote:
>> 
>> 
>> 
 then it is just going to reuse the build artifacts from last builds and 
 not checkout the sources etc.
 all those tasks will be skipped.
>> 
 why are looking for sources in a build tree ?
>> 
>> 
>> Not only source under
>> .. yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git
>> 
>> But other data such as such as the 
>> yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/* was also gone. The 
>> following image that I have it in the first place.
>
>yes thats normal when package is re-used from sstate-cache
>> 
>> 
>> 
>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/bin$
>>  ls -ltr
>> total 1424
>> -rw-r--r-- 1 dinhn dinhn 171701 Oct  5 01:17 datamodel_cache
>> -rw-r--r-- 1 dinhn dinhn 187434 Oct  5 01:17 invoke
>> -rw-r--r-- 1 dinhn dinhn 184961 Oct  5 01:17 invoke_b
>> -rw-r--r-- 1 dinhn dinhn 171701 Oct  5 01:17 protocol_infra
>> -rw-r--r-- 1 dinhn dinhn 191362 Oct  5 01:17 publisher
>> -rw-r--r-- 1 dinhn dinhn 187084 Oct  5 01:17 rpc-register
>> -rw-r--r-- 1 dinhn dinhn 179648 Oct  5 01:17 service
>> -rw-r--r-- 1 dinhn dinhn 174518 Oct  5 01:17 subscriber
>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/bin$
>>  cd ../lib
>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/lib$
>>  ls -ltr
>> total 856
>> -rw-r--r-- 3 dinhn dinhn 872657 Oct  5 01:17 libmlib.so
>> 
>> 
>> Thanks,
>>  —Dinh
>> 
>> On 10/5/16, 11:26 AM, "Khem Raj"  wrote:
>> 
>>> 
 On Oct 5, 2016, at 11:18 AM, Dinh Nguyen (dinhn)  wrote:
 
>> Are the files present in the image/packages?  Maybe it is just the
>> bitbake cache skipping doing work it already did last time.
 
 If I don’t do the bitbake clean, and just do bitbake again, then yes.
 
 
 But if I do “bitbake -c clean c-mlib” and bitbake again, the is where the 
 problem.
>>> 
>>> 
>>> well its using sstate cache here so when you do clean and rebuild and it 
>>> notices no changes from previous builds
>>> then it is just going to reuse the build artifacts from last builds and not 
>>> checkout the sources etc.
>>> all those tasks will be skipped.
>>> 
>>> why are looking for sources in a build tree ?
>>> I ask because if you want to hack on it then I would recommend following 
>>> devtool workflow.
>>> see
>>> http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#using-devtool-in-your-workflow
>>> 
>>> 
 
 Thanks,
 —Dinh
 
 
 
 
 On 10/5/16, 9:30 AM, "Lennart Sorensen"  
 wrote:
 
> On Wed, Oct 05, 2016 at 04:06:25PM +, Dinh Nguyen (dinhn) wrote:
>> Many thanks Paul. Your help is greatly appreciated.
>> 
>> 1. >>> Like the other responder I would suggest you not set PACKAGES
>> 
>> Yes, I did not set the PACKAGES, so -dev, -dbg and main packages were 
>> built as shown below:
>> 
>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find 
>> tmp/deploy | grep 
>> c-mlibtmp/deploy/ipk/core2-64/c-mlib-dbg_1.1-r0_core2-64.ipk
>> tmp/deploy/ipk/core2-64/c-mlib-dev_1.1-r0_core2-64.ipk
>> tmp/deploy/ipk/core2-64/c-mlib_1.1-r0_core2-64.ipk
>> tmp/deploy/licenses/c-mlib
>> 
>> 2. >>> FILES_${PN}-dev = "${includedir}”
>> 
>> I added that to .bb as you suggested so .so file doesn't end up in the 
>> ${PN}-dev
>> Package — No longer see the error mentioned in previous mail. Thx
>> 
>> 3. >>> This is what I suspected would happen - these files would 
>> normally be part of
>> the ${PN}-dbg package, but since you've removed that from PACKAGES, they 
>> are
>> ending up unpackaged and that is not allowed.
>> 
>> Did you mean the "install -m 0644 xxx yyy” to remove those files from 
>> the PACKAGES? How do I copy .so and binaries from my target to the 
>> libdir or bindir?
>> 
>> After changing the .bb to remove the PACKAGES setting and 
>> FILES_${PN}-dev = "${includedir}”
>> For the very first time, packages were built find, image were created 
>> under image directory and c-mlib source is still in the yp workspace as 
>> shown below:
>> 
>> A.Packages were built
>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find 
>> tmp/deploy | grep c-mlib
>> tmp/deploy/ipk/core2-64/c-mlib-dbg_1.1-r0_core2-64.ipk
>> tmp/deploy/ipk/core2-64/c-mlib-dev_1.1-r0_core2-64.ipk
>> tmp/deploy/ipk/core2-64/c-mlib_1.1-r0_core2-64.ipk
>> tmp/deploy/licenses/c-mlib
>> 
>

[yocto] SDK Problems for SuperH 4

2016-10-06 Thread Martin Townsend

Hi,

We have a poky sato distributions successfully built and running for
our SuperH 4 processor board.  The problem is the SDK that is built
when using -cpopulate_sdk doesn't.

The simple Makefile:
hellomake: HelloWorld.c
$(CC) -o HelloWorld HelloWorld.c
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK Problems for SuperH 4

2016-10-06 Thread Martin Townsend

On Thu, Oct 6, 2016 at 7:57 PM, Martin Townsend  wrote:
> Hi,
>
> We have a poky sato distributions successfully built and running for
> our SuperH 4 processor board.  The problem is the SDK that is built
> when using -cpopulate_sdk doesn't.
>
> The simple Makefile:
> hellomake: HelloWorld.c
> $(CC) -o HelloWorld HelloWorld.c

Hit send before I had chance to finish :)

ignore the missing tab but when trying to compile (after sourcing the
SDK environment) I get
sh4-poky-linux-gcc  -ml -m4
--sysroot=/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux -o HelloWorld
HelloWorld.o
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find crt1.o: No such file or directory
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find crti.o: No such file or directory
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find crtbegin.o: No such file or directory
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find -lgcc
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find -lgcc_s
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find -lc
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find -lgcc
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find -lgcc_s
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find crtend.o: No such file or directory
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
cannot find crtn.o: No such file or directory

So I tried the compiler and sysroot from the build
CC=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/x86_64-linux/usr/bin/sh4-poky-linux/sh4-poky-linux-gcc
SYSROOT=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/sh7760

hellomake: HelloWorld.c
$(CC) --sysroot=$(SYSROOT) -o HelloWorld HelloWorld.c

and it compiles fine.

So I ran $CC -print-search-dirs
install: 
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/
programs: 
=/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/
libraries: 
=/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/

Then I checked that these files exist:
martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$
find $SDKTARGETSYSROOT -name "crt*"
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crtn.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crti.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crt1.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtendS.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtend.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginT.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginS.o
/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbegin.o

Putting the library search directories on a separate line
martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$
$CC -print-search-dirs | grep "^libraries:" | tr ':' '\n'
libraries
 
=/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/
/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/

Re: [yocto] Splitting a recipe into two for two kind of compilation

2016-10-06 Thread nbigaouette

Thank you Khem, I was able to fix the conflict by adding multiple
SSTATE_DUPWHITELIST in my `.inc` file.

I couldn't find documentation for SSTATE_DUPWHITELIST, so I'm posting
the exact line I've used. The trick was to use STAGING_DIR_HOST to
specify the path to the file.

For example, for the conflicting file:

/cache/tmp/sysroots/intel-corei7-64/lib/systemd/system/mypackage.service

I added:
SSTATE_DUPWHITELIST +=
"${STAGING_DIR_HOST}${systemd_unitdir}/system/mypackage.service"

I can now build both `-release` and `-debug` packages and include them
in two separate images. Once the distro is running on the hardware, I
can simply switch between the two (by removing the first and installing
the second).

Thanks!

Nicolas

On 2016-10-05 11:56, Khem Raj wrote:

On Wed, Oct 5, 2016 at 7:20 AM, Nicolas Bigaouette
wrote:

Hi all!

I have an issue when trying to build two different images using
conflicting

packages.

I need to package an application of mine (built using cmake) for our
Yocto
deployment. The recipe is already written and works well, except that
I now

need to build two different versions of that code.

The code gets compiled to two different binaries (using `#ifdef`)
depending

on the cmake variable.

Right now I can select which code path is compiled by adding either
`EXTRA_OECMAKE += " -DCMAKE_BUILD_TYPE=Debug"` or EXTRA_OECMAKE += "
-DCMAKE_BUILD_TYPE=Release" to my recipe.

I believe I need a second recipe for a second package. I thus moved
everything that is common to an `.inc` file and created two new
recipes that

`require` that new include file. The two new recipes have a suffix to
identify which code path was compiled in (`mypackage-release` and
`mypackage-debug`). I also added an `RCONFLICTS_${PN}` line to both
recipes

to indicate conflict with the one another.

I can now build both packages using bitbake, but I cannot build two
images
(say `myimage-release` and `myimage-debug`) that will include only one
of
the package. I want `myimage-release` to include `mypackage-release`
and
`myimage-debug` should include `mypackage-debug` but I get conflicts
between

the two packages in the sysroot. Here's the log:

ERROR: The recipe mypackage-release is trying to install files into a
shared area when those files already exist. Those files and their
manifest

location are:
/cache/tmp/sysroots/intel-corei7-64/lib/systemd/system/mypackage.service
Matched in manifest-intel-corei7-64-mypackage-debug.populate_sysroot
Please verify which recipe should provide the above files.
The build has stopped as continuing in this scenario WILL break
things, if
not now, possibly in the future (we've seen builds fail several
months
later). If the system knew how to recover from this automatically it
would
however there are several different scenarios which can result in
this and
we don't know which one this is. It may be you have switched
providers of
something like virtual/kernel (e.g. from linux-yocto to
linux-yocto-dev), in
that case you need to execute the clean task for both recipes and it
will
resolve this error. It may be you changed DISTRO_FEATURES from
systemd to
udev or vice versa. Cleaning those recipes should again resolve this
error
however switching DISTRO_FEATURES on an existing build directory is
not
supported, you should really clean out tmp and rebuild (reusing
sstate
should be safe). It could be the overlapping files detected are
harmless in
which case adding them to SSTATE_DUPWHITELIST may be the correct
solution.
It could also be your build is including two different conflicting
versions
of things (e.g. bluez 4 and bluez 5 and the correct solution for that
would
be to resolve the conflict. If in doubt, please ask on the mailing
list,

sharing the error and filelist above.
ERROR: If the above message is too much, the simpler version is
you're
advised to wipe out tmp and rebuild (reusing sstate is fine). That
will

likely fix things in most (but not all) cases.
ERROR: Function failed: sstate_task_postfunc
ERROR: Logfile of failure stored in:
/cache/tmp/work/corei7-64-poky-linux/mypackage-release/1.4.99+gitAUTOINC+b34a28e86d+master-r0/temp/log.do_populate_sysroot.14559
NOTE: recipe
mypackage-release-1.4.99+gitAUTOINC+b34a28e86d+master-r0:

task do_populate_sysroot: Failed
ERROR: Task 810
(/builds/yocto/poky/../meta-proj/recipes-proj/mypackage/mypackage-release_git.bb,
do_populate_sysroot) failed with exit code '1'

Am I approaching the problem the right way? Is doing what I do the
proper

way to achieve what I want?

There are couple of ways you can look at it. There is global flag
DEBUG_BUILD
to generate debuggable images. So you could utilize that flag in a
single recipe

to control enabling/disabling debugging features of your app. This
will give better debugability to devs as well since you will have
other packages with debug friendly information.

Taking the approach you have described would work too, you have to
ensure

that two recipes i.

[yocto] [eclipse-poky][Mars] Drop bc from build

2016-10-06 Thread Tim Orling

[YOCTO #10032]

BitBake Commander has been bit-rotting for years and it was decided to
deprecate it in 2.1. Drop it from the build.

Signed-off-by: Tim Orling 
---
 features/org.yocto.sdk.site/category.xml |  4 
 features/org.yocto.sdk.site/site.xml |  2 ++
 scripts/build.sh | 11 +--
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/features/org.yocto.sdk.site/category.xml 
b/features/org.yocto.sdk.site/category.xml
index f98fc4e..33e3d62 100644
--- a/features/org.yocto.sdk.site/category.xml
+++ b/features/org.yocto.sdk.site/category.xml
@@ -6,14 +6,18 @@

   

+

   


+

http://download.eclipse.org/tm/updates/4.0/"; enabled="true" />
 
diff --git a/features/org.yocto.sdk.site/site.xml 
b/features/org.yocto.sdk.site/site.xml
index b0507b0..fa00cd2 100644
--- a/features/org.yocto.sdk.site/site.xml
+++ b/features/org.yocto.sdk.site/site.xml
@@ -7,10 +7,12 @@
   


+

   

diff --git a/scripts/build.sh b/scripts/build.sh
index cc696e7..21cfd54 100755
--- a/scripts/build.sh
+++ b/scripts/build.sh
@@ -132,15 +132,14 @@ cd ${TOP}
 echo -e "\nGenerate Yocto documentation\n"
 ${GIT_DIR}/scripts/generate-doc.sh ${DOC_REF} ${GIT_DIR} || fail $? "generate 
documentation"
 
-#build 
-java -jar ${LAUNCHER} -application org.eclipse.ant.core.antRunner -buildfile 
${BUILDFILE} -DbaseLocation=${ECLIPSE_BASE} 
-Dbuilder=${GIT_DIR}/features/org.yocto.bc.headless.build 
-DbuildDirectory=${BUILD_DIR} -DotherSrcDirectory=${GIT_DIR} 
-DbuildId=${RELEASE} || fail $? "normal build"
+#build
+java -jar ${LAUNCHER} -application org.eclipse.ant.core.antRunner -buildfile 
${BUILDFILE} -DbaseLocation=${ECLIPSE_BASE} 
-Dbuilder=${GIT_DIR}/features/org.yocto.utils.headless.build 
-DbuildDirectory=${BUILD_DIR} -DotherSrcDirectory=${GIT_DIR} 
-DbuildId=${RELEASE} || fail $? "normal build"
 java -jar ${LAUNCHER} -application org.eclipse.ant.core.antRunner -buildfile 
${BUILDFILE} -DbaseLocation=${ECLIPSE_BASE} 
-Dbuilder=${GIT_DIR}/features/org.yocto.doc.headless.build 
-DbuildDirectory=${BUILD_DIR} -DotherSrcDirectory=${GIT_DIR} 
-DbuildId=${RELEASE} || fail $? "normal build"
 java -jar ${LAUNCHER} -application org.eclipse.ant.core.antRunner -buildfile 
${BUILDFILE} -DbaseLocation=${ECLIPSE_BASE} 
-Dbuilder=${GIT_DIR}/features/org.yocto.sdk.headless.build 
-DbuildDirectory=${BUILD_DIR} -DotherSrcDirectory=${GIT_DIR} 
-DbuildId=${RELEASE} || fail $? "normal build"
 
 if [ -f ${BUILD_DIR}/I.${RELEASE}/org.yocto.sdk-${RELEASE}.zip ] &&
-   [ -f ${BUILD_DIR}/I.${RELEASE}/org.yocto.bc-${RELEASE}.zip ] &&
+   [ -f ${BUILD_DIR}/I.${RELEASE}/org.yocto.utils-${RELEASE}.zip ] &&
[ -f ${BUILD_DIR}/I.${RELEASE}/org.yocto.doc-${RELEASE}.zip ]; then
-  cp -f ${BUILD_DIR}/I.${RELEASE}/org.yocto.bc-${RELEASE}.zip 
./org.yocto.bc-${RELEASE}-${DATE}.zip
   cp -f ${BUILD_DIR}/I.${RELEASE}/org.yocto.doc-${RELEASE}.zip 
./org.yocto.doc-${RELEASE}-${DATE}.zip
   cp -f ${BUILD_DIR}/I.${RELEASE}/org.yocto.sdk-${RELEASE}.zip 
./org.yocto.sdk-${RELEASE}-${DATE}.zip
   rm -rf ${BUILD_DIR}
@@ -149,13 +148,13 @@ else
 fi
 
 #build archive for update site
-java -jar ${LAUNCHER} -application org.eclipse.ant.core.antRunner -buildfile 
${BUILDFILE} -DbaseLocation=${ECLIPSE_BASE} 
-Dbuilder=${GIT_DIR}/features/org.yocto.bc.headless.build 
-DbuildDirectory=${BUILD_DIR} -DotherSrcDirectory=${GIT_DIR} 
-DbuildId=${RELEASE} -Dp2.gathering=true || fail $? "archive build"
+java -jar ${LAUNCHER} -application org.eclipse.ant.core.antRunner -buildfile 
${BUILDFILE} -DbaseLocation=${ECLIPSE_BASE} 
-Dbuilder=${GIT_DIR}/features/org.yocto.utils.headless.build 
-DbuildDirectory=${BUILD_DIR} -DotherSrcDirectory=${GIT_DIR} 
-DbuildId=${RELEASE} -Dp2.gathering=true || fail $? "archive build"
 java -jar ${LAUNCHER} -application org.eclipse.ant.core.antRunner -buildfile 
${BUILDFILE} -DbaseLocation=${ECLIPSE_BASE} 
-Dbuilder=${GIT_DIR}/features/org.yocto.doc.headless.build 
-DbuildDirectory=${BUILD_DIR} -DotherSrcDirectory=${GIT_DIR} 
-DbuildId=${RELEASE} -Dp2.gathering=true || fail $? "archive build"
 java -jar ${LAUNCHER} -application org.eclipse.ant.core.antRunner -buildfile 
${BUILDFILE} -DbaseLocation=${ECLIPSE_BASE} 
-Dbuilder=${GIT_DIR}/features/org.yocto.sdk.headless.build 
-DbuildDirectory=${BUILD_DIR} -DotherSrcDirectory=${GIT_DIR} 
-DbuildId=${RELEASE} -Dp2.gathering=true || fail $? "archive build"
 
 #clean up
 if [ -f 
${BUILD_DIR}/I.${RELEASE}/org.yocto.sdk-${RELEASE}-group.group.group.zip ] &&
-   [ -f 
${BUILD_DIR}/I.${RELEASE}/org.yocto.bc-${RELEASE}-group.group.group.zip ] &&
+   [ -f 
${BUILD_DIR}/I.${RELEASE}/org.yocto.utils-${RELEASE}-group.group.group.zip ] &&
[ -f 
${BUILD_DIR}/I.${RELEASE}/org.yocto.doc-${RELEASE}-group.group.group.zip ]; then
   cp -f 
${BUILD_DIR}/I.${RELEASE}/org.yocto.sdk-${RELEASE}-group.group.group.zip 
./org.yocto.sdk-${RELEASE}-${DATE}-archive.zip
   rm -rf ${BUILD_TOP}
-- 
2.7.4

-- 
_

Re: [yocto] openjdk build fails due to checksum mismatches from icedtea-native

2016-10-06 Thread Randy Mortensen

> On Oct 5, 2016, at 7:14 PM, Darcy Watkins  wrote:
> 
> 
> 
>> On Oct 5, 2016, at 4:52 PM, Khem Raj  wrote:
>>> On Oct 5, 2016, at 4:45 PM, Randy Mortensen  
>>> wrote:
 On Oct 5, 2016, at 5:04 PM, Darcy Watkins  
 wrote:

 From what I gleaned from recent discussions of fetcher errors, this is 
 somehow connected with rollout of Python related security fixes to various 
 Linux distributions and/or some ...-native recipes.

 It was a bunch of tar balls that are named as mercurial hashes from within 
 iced tea rather than the yocto fetch. I worked around it by grabbing the 
 tarballs from a different checkout since I didn't have time to dig into it.

 It affected a fresh checkout I was building from scratch.

>>> Thanks for the response. This also happened to me when trying to build from 
>>> scratch.
>>> For my clarification, did you already have the tar balls downloaded or were 
>>> you able to download them from a previous (icedtea) commit somehow?
> 
> I had the tar balls in a different build that I had around for some time.  
> The reason I never cached these ones in a shared location on our server was I 
> felt that tar balls with small hashes as filenames was too prone to 
> collisions, especially without a package name as a prefix.  I don't know if 
> that is a convention of iced tea, or how the fetcher handles mercurial.
> 
>> Can you check if the tarballs have been rebuilt upstream ? if so we should 
>> try to find out what changed.
>> It could also be an oversight that a recipe update forgot or updated the 
>> checksums wrongly. but we should try to root cause it
> 
> I agree here.  We should root cause it.
> 
> 
I’m not sure how this is all supposed to work, but I managed to get past the 
fetch failures by changing the md5sum and sha256sum checksums in 
icedtea7-native_2.1.3.bb. 
I used the the checksums helpfully suggested by bitbake when it reported the 
errors. 

I compared one of the problematic tar balls with a “good” one from a previous 
download and the only change I could identify was 3 extra lines added to a 
hidden file .hgtag  (which I presume maps a tag to a commit). Not sure why 
requesting the same hg commit results in a different tarball output.

Now however iced tea fails to configure due to checksum errors. The configure 
task seems to re-download each tarball and check the sha256sum which is failing.

I’m not sure where to go from here to try and resolve so any more help is 
welcome.

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

[yocto] [meta-raspberrypi][PATCH 1/4] linux-raspberrypi_4.4: Upgrade to 4.4.23

2016-10-06 Thread Khem Raj

Drop upstreamed patch

Signed-off-by: Khem Raj 
---
 .../0002-vc4-ioctl-rendering-allow.patch   | 29 --
 recipes-kernel/linux/linux-raspberrypi_4.4.bb  |  5 ++--
 2 files changed, 2 insertions(+), 32 deletions(-)
 delete mode 100644 
recipes-kernel/linux/linux-raspberrypi-4.4/0002-vc4-ioctl-rendering-allow.patch

diff --git 
a/recipes-kernel/linux/linux-raspberrypi-4.4/0002-vc4-ioctl-rendering-allow.patch
 
b/recipes-kernel/linux/linux-raspberrypi-4.4/0002-vc4-ioctl-rendering-allow.patch
deleted file mode 100644
index 59d0ed7..000
--- 
a/recipes-kernel/linux/linux-raspberrypi-4.4/0002-vc4-ioctl-rendering-allow.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-This patch has been accepted upstream in kernel 4.7-rc3
-But it has not yet been backported to 4.4...
-Upstream-Status: Accepted 
[http://www.gossamer-threads.com/lists/linux/kernel/2459302]
-Signed-off-by: Herve Jourdain 

-
-diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
-index a5b68c1..14b5ec1 100644
 a/drivers/gpu/drm/vc4/vc4_drv.c
-+++ b/drivers/gpu/drm/vc4/vc4_drv.c
-@@ -75,12 +75,12 @@ static const struct file_operations vc4_drm_fops = {
- };
- 
- static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
--  DRM_IOCTL_DEF_DRV(VC4_SUBMIT_CL, vc4_submit_cl_ioctl, 0),
--  DRM_IOCTL_DEF_DRV(VC4_WAIT_SEQNO, vc4_wait_seqno_ioctl, 0),
--  DRM_IOCTL_DEF_DRV(VC4_WAIT_BO, vc4_wait_bo_ioctl, 0),
--  DRM_IOCTL_DEF_DRV(VC4_CREATE_BO, vc4_create_bo_ioctl, 0),
--  DRM_IOCTL_DEF_DRV(VC4_MMAP_BO, vc4_mmap_bo_ioctl, 0),
--  DRM_IOCTL_DEF_DRV(VC4_CREATE_SHADER_BO, vc4_create_shader_bo_ioctl, 0),
-+  DRM_IOCTL_DEF_DRV(VC4_SUBMIT_CL, vc4_submit_cl_ioctl, 
0|DRM_RENDER_ALLOW),
-+  DRM_IOCTL_DEF_DRV(VC4_WAIT_SEQNO, vc4_wait_seqno_ioctl, 
0|DRM_RENDER_ALLOW),
-+  DRM_IOCTL_DEF_DRV(VC4_WAIT_BO, vc4_wait_bo_ioctl, 0|DRM_RENDER_ALLOW),
-+  DRM_IOCTL_DEF_DRV(VC4_CREATE_BO, vc4_create_bo_ioctl, 
0|DRM_RENDER_ALLOW),
-+  DRM_IOCTL_DEF_DRV(VC4_MMAP_BO, vc4_mmap_bo_ioctl, 0|DRM_RENDER_ALLOW),
-+  DRM_IOCTL_DEF_DRV(VC4_CREATE_SHADER_BO, vc4_create_shader_bo_ioctl, 
0|DRM_RENDER_ALLOW),
-   DRM_IOCTL_DEF_DRV(VC4_GET_HANG_STATE, vc4_get_hang_state_ioctl,
- DRM_ROOT_ONLY),
- };
diff --git a/recipes-kernel/linux/linux-raspberrypi_4.4.bb 
b/recipes-kernel/linux/linux-raspberrypi_4.4.bb
index 9a49dc1..4b15f88 100644
--- a/recipes-kernel/linux/linux-raspberrypi_4.4.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_4.4.bb
@@ -1,10 +1,9 @@
 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
 
-LINUX_VERSION ?= "4.4.16"
+LINUX_VERSION ?= "4.4.23"
 
-SRCREV = "cff67c7e03f4333149f2a8f6eafd3bc44475114a"
+SRCREV = "c2a1d975537fcac01da80ce34f10bc491620a64e"
 SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.4.y \
file://0001-fix-dtbo-rules.patch \
-   file://0002-vc4-ioctl-rendering-allow.patch \
 "
 require linux-raspberrypi.inc
-- 
2.10.0

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

[yocto] [meta-raspberrypi][PATCH 3/4] firmware: Upgrade to latest

2016-10-06 Thread Khem Raj

Signed-off-by: Khem Raj 
---
 recipes-bsp/common/firmware.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/common/firmware.inc b/recipes-bsp/common/firmware.inc
index a9d2327..29f9c01 100644
--- a/recipes-bsp/common/firmware.inc
+++ b/recipes-bsp/common/firmware.inc
@@ -1,5 +1,5 @@
-RPIFW_SRCREV ?= "1205048f037098b1532bb947d1f4b823bcdebdf7"
-RPIFW_DATE ?= "20160726"
+RPIFW_SRCREV ?= "ec63df146f454e8cab7080380f9138246d877013"
+RPIFW_DATE ?= "20161005"
 RPIFW_SRC_URI ?= 
"git://github.com/raspberrypi/firmware.git;protocol=git;branch=master"
 RPIFW_S ?= "${WORKDIR}/git"
 
-- 
2.10.0

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

[yocto] [meta-raspberrypi][PATCH 2/4] userland: Upgrade to latest

2016-10-06 Thread Khem Raj

Signed-off-by: Khem Raj 
---
 ...-applications-to-set-next-resource-handle.patch |  6 ++---
 ...ayland-Add-support-for-the-Wayland-winsys.patch | 28 +++---
 .../0003-wayland-Add-Wayland-example.patch |  4 ++--
 ...-wayland-egl-Add-bcm_host-to-dependencies.patch |  4 ++--
 ...emove-faulty-assert-to-make-weston-happy-.patch | 22 -
 ...6-zero-out-wl-buffers-in-egl_surface_free.patch |  4 ++--
 ...007-initialize-front-back-wayland-buffers.patch |  4 ++--
 .../userland/userland/0008-Remove-RPC_FLUSH.patch  |  4 ++--
 .../userland/0009-fix-cmake-dependency-race.patch  |  6 ++---
 .../0010-Fix-enum-conversion-warnings.patch|  4 ++--
 ...Fix-for-framerate-with-nested-composition.patch |  6 ++---
 .../0012-build-shared-library-for-vchostif.patch   |  6 ++---
 ...nt-buffer-wrapping-interface-for-dispmanx.patch |  4 ++--
 recipes-graphics/userland/userland_git.bb  |  2 +-
 14 files changed, 52 insertions(+), 52 deletions(-)

diff --git 
a/recipes-graphics/userland/userland/0001-Allow-applications-to-set-next-resource-handle.patch
 
b/recipes-graphics/userland/userland/0001-Allow-applications-to-set-next-resource-handle.patch
index 8c855da..b5bf461 100644
--- 
a/recipes-graphics/userland/userland/0001-Allow-applications-to-set-next-resource-handle.patch
+++ 
b/recipes-graphics/userland/userland/0001-Allow-applications-to-set-next-resource-handle.patch
@@ -1,4 +1,4 @@
-From a096ab4b7bbdd8f78d93a54a8da1ca3c9470c2ec Mon Sep 17 00:00:00 2001
+From 2b87c1271a5b2fc60a7bcfcaf902f3ef69ccad24 Mon Sep 17 00:00:00 2001
 From: Dom Cobley 
 Date: Tue, 9 Jul 2013 09:26:26 -0400
 Subject: [PATCH 01/13] Allow applications to set next resource handle
@@ -56,7 +56,7 @@ index 8378f4a..ec961e0 100644
  #define EGLINTFLUSH_ID0x400c
  #define EGLINTGETCOLORDATA_ID 0x400d
 diff --git a/interface/khronos/egl/egl_client.c 
b/interface/khronos/egl/egl_client.c
-index 472ef0c..234da65 100644
+index 9d617c8..b8bb374 100644
 --- a/interface/khronos/egl/egl_client.c
 +++ b/interface/khronos/egl/egl_client.c
 @@ -162,6 +162,17 @@ static void egl_current_release(CLIENT_PROCESS_STATE_T 
*process, EGL_CURRENT_T *
@@ -204,5 +204,5 @@ index 8a5734c..51b3580 100644
  
  FN(void, eglIntGetColorData_impl, (EGL_SURFACE_ID_T s, KHRN_IMAGE_FORMAT_T 
format, uint32_t width, uint32_t height, int32_t stride, uint32_t y_offset, 
void *data))
 -- 
-2.9.0
+2.10.0
 
diff --git 
a/recipes-graphics/userland/userland/0002-wayland-Add-support-for-the-Wayland-winsys.patch
 
b/recipes-graphics/userland/userland/0002-wayland-Add-support-for-the-Wayland-winsys.patch
index 00c96d5..2abe5ce 100644
--- 
a/recipes-graphics/userland/userland/0002-wayland-Add-support-for-the-Wayland-winsys.patch
+++ 
b/recipes-graphics/userland/userland/0002-wayland-Add-support-for-the-Wayland-winsys.patch
@@ -1,4 +1,4 @@
-From 75ce950e68a0260ea5da56a83c27eb46331d819f Mon Sep 17 00:00:00 2001
+From 3a0e094a6aac53c9ddc4b28feb77cfc1a319880d Mon Sep 17 00:00:00 2001
 From: Tomeu Vizoso 
 Date: Tue, 1 Oct 2013 13:19:20 +0200
 Subject: [PATCH 02/13] wayland: Add support for the Wayland winsys
@@ -58,17 +58,17 @@ vc_vchi_dispmanx.h
  create mode 100644 makefiles/cmake/Wayland.cmake
 
 diff --git a/.gitignore b/.gitignore
-index 8df9393..d0d1387 100644
+index 4a88665..5da71a9 100644
 --- a/.gitignore
 +++ b/.gitignore
-@@ -10,3 +10,5 @@
+@@ -13,3 +13,5 @@ build/
  *.lai
  *.la
  *.a
 +
 +*~
 diff --git a/CMakeLists.txt b/CMakeLists.txt
-index a12e389..f0fde45 100644
+index d3159c7..58eb8f7 100644
 --- a/CMakeLists.txt
 +++ b/CMakeLists.txt
 @@ -19,6 +19,17 @@ include(makefiles/cmake/global_settings.cmake)
@@ -102,12 +102,12 @@ index 358d2b4..4da4448 100644
 +
 +$ BUILD_WAYLAND=1 ./buildme.
 diff --git a/buildme b/buildme
-index 9e9d4d7..4e5d0be 100755
+index d778276..f509864 100755
 --- a/buildme
 +++ b/buildme
 @@ -8,6 +8,10 @@ fi
  
- BUILDSUBDIR=`echo $BUILDTYPE | tr [A-Z] [a-z]`;
+ BUILDSUBDIR=`echo $BUILDTYPE | tr '[A-Z]' '[a-z]'`;
  
 +if [ -n "$BUILD_WAYLAND" ]; then
 +   WAYLAND_VARS="-DBUILD_WAYLAND=TRUE"
@@ -340,7 +340,7 @@ index 4f3ce49..84f6ec0 100644
  /* OpenGL ES 1.1 and 2.0 functions */
  
 diff --git a/interface/khronos/common/linux/khrn_client_platform_linux.c 
b/interface/khronos/common/linux/khrn_client_platform_linux.c
-index 3320b33..39fc7cc 100644
+index 710d20f..50d60a6 100644
 --- a/interface/khronos/common/linux/khrn_client_platform_linux.c
 +++ b/interface/khronos/common/linux/khrn_client_platform_linux.c
 @@ -37,6 +37,11 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
@@ -355,7 +355,7 @@ index 3320b33..39fc7cc 100644
  extern VCOS_LOG_CAT_T khrn_client_log;
  
  extern void vc_vchi_khronos_init();
-@@ -462,13 +467,36 @@ EGLDisplay 
khrn_platform_set_display_id(EGLNativeDisplayType display_id)
+@@ -464,13 +469,36 @@ EGLDisplay 
khrn_platform_set_display_id(EGLNativeDisplayType display_id)
   return EGL_NO_DISPLAY;
  }
  #else
@@ -394,7 +394,7 @@ index 3320b33..39

[yocto] [meta-raspberrypi][PATCH 4/4] sdcard_image-rpi.bbclass: Remove redundant RPI_KERNEL_VERSION

2016-10-06 Thread Khem Raj

From: Jonathan Liu 

The value of the RPI_KERNEL_VERSION can change between None and the
kernel version which can result in taskhash mismatch errors while
building images.

The taskhash mismatch errors can be reproduced using:
bitbake -c cleansstate virtual/kernel core-image-minimal && bitbake 
core-image-minimal

The get_dts() and split_overlays() functions are modified so that the
kernel version argument is optional. If the version is not supplied to
these functions, they will fallback to the Python equivalent of the
expression used for RPI_KERNEL_VERSION.

Signed-off-by: Jonathan Liu 
Signed-off-by: Khem Raj 
---
 classes/linux-raspberrypi-base.bbclass | 4 ++--
 classes/sdcard_image-rpi.bbclass   | 8 +++-
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/classes/linux-raspberrypi-base.bbclass 
b/classes/linux-raspberrypi-base.bbclass
index 930fc44..3a6e33d 100644
--- a/classes/linux-raspberrypi-base.bbclass
+++ b/classes/linux-raspberrypi-base.bbclass
@@ -1,6 +1,6 @@
 inherit linux-kernel-base
 
-def get_dts(d, ver):
+def get_dts(d, ver=None):
 import re
 
 staging_dir = d.getVar("STAGING_KERNEL_BUILDDIR", True)
@@ -32,7 +32,7 @@ def get_dts(d, ver):
 return dts
 
 
-def split_overlays(d, ver, out):
+def split_overlays(d, out, ver=None):
 dts = get_dts(d, ver)
 if out:
 overlays = oe.utils.str_filter_out('\S+\-overlay\.dtb$', dts, d)
diff --git a/classes/sdcard_image-rpi.bbclass b/classes/sdcard_image-rpi.bbclass
index 2f0daee..0487ef1 100644
--- a/classes/sdcard_image-rpi.bbclass
+++ b/classes/sdcard_image-rpi.bbclass
@@ -71,8 +71,6 @@ SDIMG = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.rpi-sdimg"
 # Additional files and/or directories to be copied into the vfat partition 
from the IMAGE_ROOTFS.
 FATPAYLOAD ?= ""
 
-RPI_KERNEL_VERSION := 
"${@get_kernelversion_file('${STAGING_KERNEL_BUILDDIR}')}"
-
 IMAGE_CMD_rpi-sdimg () {
 
# Align partitions
@@ -83,7 +81,7 @@ IMAGE_CMD_rpi-sdimg () {
echo "Creating filesystem with Boot partition ${BOOT_SPACE_ALIGNED} KiB 
and RootFS $ROOTFS_SIZE KiB"
 
# Check if we are building with device tree support
-   DTS="${@get_dts(d, '${RPI_KERNEL_VERSION}')}"
+   DTS="${@get_dts(d)}"
 
# Initialize sdcard image file
dd if=/dev/zero of=${SDIMG} bs=1024 count=0 seek=${SDIMG_SIZE}
@@ -104,8 +102,8 @@ IMAGE_CMD_rpi-sdimg () {
mcopy -i ${WORKDIR}/boot.img -s ${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/* 
::/
if test -n "${DTS}"; then
# Device Tree Overlays are assumed to be suffixed by 
'-overlay.dtb' (4.1.x) or by '.dtbo' (4.4.9+) string and will be put in a 
dedicated folder
-   DT_OVERLAYS="${@split_overlays(d, '${RPI_KERNEL_VERSION}', 0)}"
-   DT_ROOT="${@split_overlays(d, '${RPI_KERNEL_VERSION}', 1)}"
+   DT_OVERLAYS="${@split_overlays(d, 0)}"
+   DT_ROOT="${@split_overlays(d, 1)}"
 
# Copy board device trees to root folder
for DTB in ${DT_ROOT}; do
-- 
2.10.0

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

Re: [yocto] openjdk build fails due to checksum mismatches from icedtea-native

2016-10-06 Thread Khem Raj


> On Oct 6, 2016, at 7:07 PM, Randy Mortensen  wrote:
> 
> 
>> On Oct 5, 2016, at 7:14 PM, Darcy Watkins  
>> wrote:
>> 
>> 
>> 
>>> On Oct 5, 2016, at 4:52 PM, Khem Raj  wrote:
 On Oct 5, 2016, at 4:45 PM, Randy Mortensen  
 wrote:
> On Oct 5, 2016, at 5:04 PM, Darcy Watkins  
> wrote:
> 
> From what I gleaned from recent discussions of fetcher errors, this is 
> somehow connected with rollout of Python related security fixes to 
> various Linux distributions and/or some ...-native recipes.
> 
> It was a bunch of tar balls that are named as mercurial hashes from 
> within iced tea rather than the yocto fetch. I worked around it by 
> grabbing the tarballs from a different checkout since I didn't have time 
> to dig into it.
> 
> It affected a fresh checkout I was building from scratch.
> 
 Thanks for the response. This also happened to me when trying to build 
 from scratch.
 For my clarification, did you already have the tar balls downloaded or 
 were you able to download them from a previous (icedtea) commit somehow?
>> 
>> I had the tar balls in a different build that I had around for some time.  
>> The reason I never cached these ones in a shared location on our server was 
>> I felt that tar balls with small hashes as filenames was too prone to 
>> collisions, especially without a package name as a prefix.  I don't know if 
>> that is a convention of iced tea, or how the fetcher handles mercurial.
>> 
>>> Can you check if the tarballs have been rebuilt upstream ? if so we should 
>>> try to find out what changed.
>>> It could also be an oversight that a recipe update forgot or updated the 
>>> checksums wrongly. but we should try to root cause it
>> 
>> I agree here.  We should root cause it.
>> 
>> 
> I’m not sure how this is all supposed to work, but I managed to get past the 
> fetch failures by changing the md5sum and sha256sum checksums in 
> icedtea7-native_2.1.3.bb.
> I used the the checksums helpfully suggested by bitbake when it reported the 
> errors.
> 
> I compared one of the problematic tar balls with a “good” one from a previous 
> download and the only change I could identify was 3 extra lines added to a 
> hidden file .hgtag  (which I presume maps a tag to a commit). Not sure why 
> requesting the same hg commit results in a different tarball output.
> 

could it be that its generating the tarballs from mercurial directly and thats 
flawed somehow ?


> Now however iced tea fails to configure due to checksum errors. The configure 
> task seems to re-download each tarball and check the sha256sum which is 
> failing.
> 
> I’m not sure where to go from here to try and resolve so any more help is 
> welcome.



> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK Problems for SuperH 4

2016-10-06 Thread Khem Raj


> On Oct 6, 2016, at 12:09 PM, Martin Townsend  wrote:
> 
> On Thu, Oct 6, 2016 at 7:57 PM, Martin Townsend  
> wrote:
>> Hi,
>> 
>> We have a poky sato distributions successfully built and running for
>> our SuperH 4 processor board.  The problem is the SDK that is built
>> when using -cpopulate_sdk doesn't.
>> 
>> The simple Makefile:
>> hellomake: HelloWorld.c
>> $(CC) -o HelloWorld HelloWorld.c
> 
> Hit send before I had chance to finish :)
> 
> ignore the missing tab but when trying to compile (after sourcing the
> SDK environment) I get
> sh4-poky-linux-gcc  -ml -m4
> --sysroot=/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux -o HelloWorld
> HelloWorld.o
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find crt1.o: No such file or directory
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find crti.o: No such file or directory
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find crtbegin.o: No such file or directory
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find -lgcc
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find -lgcc_s
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find -lc
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find -lgcc
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find -lgcc_s
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find crtend.o: No such file or directory
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/real-ld:
> cannot find crtn.o: No such file or directory
> 
> So I tried the compiler and sysroot from the build
> CC=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/x86_64-linux/usr/bin/sh4-poky-linux/sh4-poky-linux-gcc
> SYSROOT=/ws/vms/vms-rsc-yocto-build/build_vms/tmp/sysroots/sh7760
> 
> hellomake: HelloWorld.c
> $(CC) --sysroot=$(SYSROOT) -o HelloWorld HelloWorld.c
> 
> and it compiles fine.
> 
> So I ran $CC -print-search-dirs
> install: 
> /opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/
> programs: 
> =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/bin/
> libraries: 
> =/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/sh4-poky-linux/gcc/sh4-poky-linux/4.9.3/../../../../../sh4-poky-linux/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/lib/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/sh4-poky-linux/4.9.3/:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/m4/usr/lib/
> 
> Then I checked that these files exist:
> martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$
> find $SDKTARGETSYSROOT -name "crt*"
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crtn.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crti.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/crt1.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtendS.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtend.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginT.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbeginS.o
> /opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux/usr/lib/sh4-poky-linux/4.9.3/crtbegin.o
> 
> Putting the library search directories on a separate line
> martin@martin-ubuntu-pconcepts:/opt/sdk/vms/2.0.2/sysroots/sh4-poky-linux$
> $CC -print-search-dir

[yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: Add recipes and patches for 4.8 release

2016-10-06 Thread Khem Raj

Signed-off-by: Khem Raj 
---
 .../0001-fix-dtbo-rules.patch  | 44 ++
 ...835-camera-fix-compilation-warning-werror.patch | 35 +
 recipes-kernel/linux/linux-raspberrypi_4.8.bb  | 10 +
 3 files changed, 89 insertions(+)
 create mode 100644 
recipes-kernel/linux/linux-raspberrypi-4.8/0001-fix-dtbo-rules.patch
 create mode 100644 
recipes-kernel/linux/linux-raspberrypi-4.8/0001-media-bcm2835-camera-fix-compilation-warning-werror.patch
 create mode 100644 recipes-kernel/linux/linux-raspberrypi_4.8.bb

diff --git 
a/recipes-kernel/linux/linux-raspberrypi-4.8/0001-fix-dtbo-rules.patch 
b/recipes-kernel/linux/linux-raspberrypi-4.8/0001-fix-dtbo-rules.patch
new file mode 100644
index 000..5113e23
--- /dev/null
+++ b/recipes-kernel/linux/linux-raspberrypi-4.8/0001-fix-dtbo-rules.patch
@@ -0,0 +1,44 @@
+From 13c8784da3dbd977f64cec740eba775b6fab11c2 Mon Sep 17 00:00:00 2001
+From: Herve Jourdain 
+Date: Fri, 20 May 2016 16:02:23 +0800
+Subject: [yocto][meta-raspberrypi][PATCH v4 4/5] linux-raspberrypi_4.4.inc:
+ support for .dtbo files for dtb overlays
+
+Upstream-Status: Pending
+
+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
+
+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/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
++  $(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) ; \
diff --git 
a/recipes-kernel/linux/linux-raspberrypi-4.8/0001-media-bcm2835-camera-fix-compilation-warning-werror.patch
 
b/recipes-kernel/linux/linux-raspberrypi-4.8/0001-media-bcm2835-camera-fix-compilation-warning-werror.patch
new file mode 100644
index 000..ea9778f
--- /dev/null
+++ 
b/recipes-kernel/linux/linux-raspberrypi-4.8/0001-media-bcm2835-camera-fix-compilation-warning-werror.patch
@@ -0,0 +1,35 @@
+From a8151cbe5d92d7487b7994522cbc83fed04ae1f9 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Thu, 6 Oct 2016 19:42:55 -0700
+Subject: [PATCH] [media]: bcm2835-camera: fix compilation warning/werror
+
+| 
/a/builder/mnt/build/tmp-glibc/work-shared/raspberrypi3/kernel-source/drivers/media/platform/bcm2835/bcm2835-camera.c:656:17:
 error: initialization from incompatible pointer type 
[-Werror=incompatible-pointer-types
+]
+|   .queue_setup = queue_setup,
+|  ^~~
+| 
/a/builder/mnt/build/tmp-glibc/work-shared/raspberrypi3/kernel-source/drivers/media/platform/bcm2835/bcm28
+35-camera.c:656:17: note: (near initialization for 
'bm2835_mmal_video_qops.queue_setup')
+
+use struct device* instead of void*
+
+Signed-off-by: Khem Raj 
+---
+ drivers/media/platform/bcm2835/bcm2835-camera.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/media/platform/bcm2835/bcm2835-camera.c 
b/drivers/media/platform/bcm2835/bcm2835-camera.c
+index 70f4db2..cb5bab6 100644
+--- a/drivers/media/platform/bcm2835/bcm2835-camera.c
 b/drivers/media/platform/bcm2835/bcm2835-camera.c
+@@ -244,7 +244,7 @@ static struct mmal_fmt *get_format(struct v4l2_format *f)
+ 
+ static int queue_setup(struct vb2_queue *vq,
+  unsigned int *nbuffers, unsigned int *nplanes,
+- unsigned int sizes[], void *alloc_ctxs[])
++ unsigned int sizes[], struct device *alloc_ctxs[])
+ {
+   struct bm2835_mmal_dev *dev = vb2_get_drv_priv(vq);
+   unsigned long size;
+-- 
+2.10.0
+
diff --git a/recipes-kernel/linux/linux-raspberrypi_4.8.bb 
b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
new file mode 100644
index 000..92a69ad
--- /dev/null
+++ b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
@@ -0,0 +1,10 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
+
+LINUX_VERSION ?= "4.8.0"
+
+SRCREV = "2fb843e0e50b2330e76acea03ff63a5b2b1e411f"
+SRC_URI = 
"git://github.com/raspberrypi/l

Re: [yocto] which meta-intel woudl build a kernel 4.8

2016-10-06 Thread VanCutsem, Geoffroy

 Original message 
From: "Dominig ar Foll (Intel Open Source)" 
Date: 06/10/2016 20:16 (GMT+01:00)
To: yocto@yoctoproject.org
Subject: [yocto] which meta-intel woudl build a kernel 4.8

Hello,

I was happily under 'jethro' until now but I need to build a kernel 4.8
fir Intel HW to get access to some new features.

I can see that the 'master' branch bump to 4.8 but unfortunately come
with the following errors :

ERROR: No recipes available for:

/home/dominig/AGL/meta-intel/common/recipes-kernel/linux/linux-yocto-tiny_4.8.bbappend

/home/dominig/AGL/meta-intel/common/recipes-kernel/linux/linux-yocto_4.8.bbappend

Would someone have an idea how I could get a 4.8 working meta-intel ?

[Geoffroy] I don't know how the overall AGL repo is constructed but it sounds 
like you would need to update your openembedded-core as well to master to have 
the base recipes for 4.8 (in meta/recipes-kernel/linux)

Geoffroy

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

Re: [yocto] [[yocto-autobuilder][PATCHv3]] Build sets to test new OS distribution in autobuilder

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: remove redundant IMAGEDATESTAMP

[yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: Remove redundant RPI_KERNEL_VERSION

[yocto] [x32 ABI] Bit size mismatch in grub-efi

[yocto] PSPLASH behavior during shutdown

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: Remove redundant RPI_KERNEL_VERSION

Re: [yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: Remove redundant RPI_KERNEL_VERSION

[yocto] which meta-intel woudl build a kernel 4.8

Re: [yocto] which meta-intel woudl build a kernel 4.8

Re: [yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

[yocto] SDK Problems for SuperH 4

Re: [yocto] SDK Problems for SuperH 4

Re: [yocto] Splitting a recipe into two for two kind of compilation

[yocto] [eclipse-poky][Mars] Drop bc from build

Re: [yocto] openjdk build fails due to checksum mismatches from icedtea-native

[yocto] [meta-raspberrypi][PATCH 1/4] linux-raspberrypi_4.4: Upgrade to 4.4.23

[yocto] [meta-raspberrypi][PATCH 3/4] firmware: Upgrade to latest

[yocto] [meta-raspberrypi][PATCH 2/4] userland: Upgrade to latest

[yocto] [meta-raspberrypi][PATCH 4/4] sdcard_image-rpi.bbclass: Remove redundant RPI_KERNEL_VERSION

Re: [yocto] openjdk build fails due to checksum mismatches from icedtea-native

Re: [yocto] SDK Problems for SuperH 4

[yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: Add recipes and patches for 4.8 release

Re: [yocto] which meta-intel woudl build a kernel 4.8

23 matches

Site Navigation

Mail list logo

Footer information