Re: [yocto] [meta-raspberrypi][PATCH 1/4] linux-raspberrypi_4.4: Upgrade to 4.4.23
On Thu, Oct 06, 2016 at 07:09:03PM -0700, Khem Raj wrote:
> 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
Merged to master the entire patch set. Thanks.
--
Andrei Gherzan
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH V2 1/2] linux-raspberrypi: Add recipe for 4.8 release
On Thu, Oct 13, 2016 at 01:15:31AM -0700, Khem Raj wrote:
> Signed-off-by: Khem Raj
> ---
> recipes-kernel/linux/linux-raspberrypi_4.8.bb | 8
> 1 file changed, 8 insertions(+)
> create mode 100644 recipes-kernel/linux/linux-raspberrypi_4.8.bb
>
> 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..02623f4
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
> @@ -0,0 +1,8 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
> +
> +LINUX_VERSION ?= "4.8.1"
> +
> +SRCREV = "5b7970b19bbb2ea1620591bfb6517848696ed0b9"
> +SRC_URI =
> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.8.y \
> +"
> +require linux-raspberrypi.inc
> --
> 2.10.0
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
Compiled both 4.7.X and 4.8.X and it's a go. Merged to master. Thanks.
--
Andrei Gherzan
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto recipe license
On 14 October 2016 at 06:23, Contrib Open Source < contrib.open.sou...@gmail.com> wrote: > Here "metadata" stands for "oe-core recipe", right ? > "metadata" includes all the recipes and classes in oe-core. > What if we extend (*.bbappend) a GPLv2 recipe: is it "contaminated" or not > ? > Presumably (note: I Am Not A Lawyer), which is why metadata is licensed under the MIT. Ross -- ___ 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
On Thu, Oct 06, 2016 at 05:55:05PM +0200, Andreas Müller wrote:
> 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
Good stuff. This explains a lot. Was merged in master. We should
backport this in krogoth branch too.
--
Andrei Gherzan
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration info - runqemu
Hi Robert, On 2016-10-14 05:12, Robert Yang wrote: QB_SYSTEM_NAME: qemu name, e.g., "qemu-system-i386" QB_OPT_APPEND: options to append to qemu, e.g., "-show-cursor" ... Could you also please mention which of those values are obligatory and what are the default values in case they are not contained in the config file? Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] add dejavu-fonts to image
Ok, i will test this week end and let you know !
Otherwise, if you build qt5.7 perhaps you can have the same issue like
me with sdk, see here for more details :
https://github.com/graugans/meta-udoo/issues/20
regards
Le 13/10/2016 à 18:12, Michel D'HOOGE a écrit :
After solving all the QA issues, this bbappend creates RPM packages with fonts
in the expected folder. I didn't try to generate an image but I'm quite
confident about the result.
Michel
do_install() {
install -d ${D}${libdir}/fonts/
find ./ -name '*.tt[cf]' -exec install -m 0644 {} ${D}${libdir}/fonts/ \;
install -d ${D}${sysconfdir}/fonts/conf.d/
install -m 0644 ${WORKDIR}/30-dejavu-aliases.conf
${D}${sysconfdir}/fonts/conf.d/
}
FILES_${PN}-sans= "${libdir}/fonts/DejaVuSans.ttf
${libdir}/fonts/DejaVuSans-*.ttf"
FILES_${PN}-sans-mono = "${libdir}/fonts/DejaVuSansMono*.ttf"
FILES_${PN}-sans-condensed = "${libdir}/fonts/DejaVuSansCondensed*.ttf"
FILES_${PN}-serif = "${libdir}/fonts/DejaVuSerif.ttf
${libdir}/fonts/DejaVuSerif-*.ttf"
FILES_${PN}-serif-condensed = "${libdir}/fonts/DejaVuSerifCondensed*.ttf"
FILES_${PN}-mathtexgyre = "${libdir}/fonts/DejaVuMathTeXGyre.ttf"
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration info - runqemu
On Fri, 2016-10-14 at 10:12 +0800, Robert Yang wrote: > Hi Paul and Scott, > > Here it is, and please feel free to comment, most of them are from > qemuboot.bbclass: > > The new runqemu is a python script, it requires a > -.qemuboot.conf to boot the bsp, the > qemuboot.conf > is generated by qemuboot.bbclass during build rootfs, qemu boot > arguments can be set in bsp's conf file, and qemuboot.bbclass will > save > them to qemuboot.conf. Can we also document when qemuboot.conf required and what benefits it brings? Previous usage patterns should also be supported, right? Thanks, Joshua > > Note, "QB" means Qemu Boot, the following vars can be set in conf > files, such as to make it can be boot by runqemu: > > QB_SYSTEM_NAME: qemu name, e.g., "qemu-system-i386" > QB_OPT_APPEND: options to append to qemu, e.g., "-show-cursor" > QB_DEFAULT_KERNEL: default kernel to boot, e.g., "bzImage" > QB_DEFAULT_FSTYPE: default FSTYPE to boot, e.g., "ext4" > QB_MEM: memory, e.g., "-m 512" > QB_MACHINE: qemu machine, e.g., "-machine virt" > QB_CPU: qemu cpu, e.g., "-cpu qemu32" > QB_CPU_KVM: the similar to QB_CPU, but used when kvm, e.g., '-cpu > kvm64', > set it when support kvm. > QB_KERNEL_CMDLINE_APPEND: options to append to kernel's -append > option, e.g., "console=ttyS0 console=tty" > QB_DTB: qemu dtb name > QB_AUDIO_DRV: qemu audio driver, e.g., "alsa", set it when support > audio > QB_AUDIO_OPT: qemu audio option, e.g., "-soundhw ac97,es1370", used > when QB_AUDIO_DRV is set. > QB_KERNEL_ROOT: kernel's root, e.g., /dev/vda > QB_TAP_OPT: netowrk option for 'tap' mode, e.g., > "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=n > o -device > virtio-net-device,netdev=net0" > Note, runqemu will replace "@TAP@" with the one which > is used, > such as tap0, tap1 ... > QB_SLIRP_OPT: network option for SLIRP mode, e.g., > "-netdev user,id=net0 -device virtio-net- > device,netdev=net0" > QB_ROOTFS_OPT: used as rootfs, e.g., > "-drive id=disk0,file=@ROOTFS@,if=none,format=raw > -device > virtio-blk-device,drive=disk0" > Note, runqemu will replace "@ROOTFS@" with the one > which is used, > such as core-image-minimal-qemuarm64.ext4. > QB_SERIAL_OPT: serial port, e.g., "-serial mon:stdio" > QB_TCPSERIAL_OPT: tcp serial port option, e.g., > " -device virtio-serial-device -chardev > socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device > virtconsole,chardev=virtcon" > Note, runqemu will replace "@PORT@" with the port > number > which is used. > > Usage: > IMAGE_CLASSES += "qemuboot" > See "runqemu help" for more info > > // Robert > > On 10/14/2016 09:48 AM, Paul Eggleton wrote: > > > > Hi folks, > > > > We need some info for the migration section of the 2.2 manual about > > what the > > user needs to do to adapt to the new python-based runqemu. Robert / > > Joshua, > > can one of you please write something short that explains what > > users need to > > do (i.e. changes to the metadata for BSPs, or any other changes in > > operation)? > > It doesn't need to be polished, Scott Rifenbark will take care of > > that. Just > > replying to this email with Scott on CC should be sufficient. > > > > Thanks, > > Paul > > - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration info - runqemu
On 10/14/2016 04:35 PM, Lock, Joshua G wrote: On Fri, 2016-10-14 at 10:12 +0800, Robert Yang wrote: Hi Paul and Scott, Here it is, and please feel free to comment, most of them are from qemuboot.bbclass: The new runqemu is a python script, it requires a -.qemuboot.conf to boot the bsp, the qemuboot.conf is generated by qemuboot.bbclass during build rootfs, qemu boot arguments can be set in bsp's conf file, and qemuboot.bbclass will save them to qemuboot.conf. Can we also document when qemuboot.conf required and what benefits it brings? Previous usage patterns should also be supported, right? Yes, the benefit is that the machine knowledge are not hardcoded into runqemu any more, the bsp can define its own arguments to make it can be boot by runqemu. And previous usage patterns also be supported. // Robert Thanks, Joshua Note, "QB" means Qemu Boot, the following vars can be set in conf files, such as to make it can be boot by runqemu: QB_SYSTEM_NAME: qemu name, e.g., "qemu-system-i386" QB_OPT_APPEND: options to append to qemu, e.g., "-show-cursor" QB_DEFAULT_KERNEL: default kernel to boot, e.g., "bzImage" QB_DEFAULT_FSTYPE: default FSTYPE to boot, e.g., "ext4" QB_MEM: memory, e.g., "-m 512" QB_MACHINE: qemu machine, e.g., "-machine virt" QB_CPU: qemu cpu, e.g., "-cpu qemu32" QB_CPU_KVM: the similar to QB_CPU, but used when kvm, e.g., '-cpu kvm64', set it when support kvm. QB_KERNEL_CMDLINE_APPEND: options to append to kernel's -append option, e.g., "console=ttyS0 console=tty" QB_DTB: qemu dtb name QB_AUDIO_DRV: qemu audio driver, e.g., "alsa", set it when support audio QB_AUDIO_OPT: qemu audio option, e.g., "-soundhw ac97,es1370", used when QB_AUDIO_DRV is set. QB_KERNEL_ROOT: kernel's root, e.g., /dev/vda QB_TAP_OPT: netowrk option for 'tap' mode, e.g., "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=n o -device virtio-net-device,netdev=net0" Note, runqemu will replace "@TAP@" with the one which is used, such as tap0, tap1 ... QB_SLIRP_OPT: network option for SLIRP mode, e.g., "-netdev user,id=net0 -device virtio-net- device,netdev=net0" QB_ROOTFS_OPT: used as rootfs, e.g., "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0" Note, runqemu will replace "@ROOTFS@" with the one which is used, such as core-image-minimal-qemuarm64.ext4. QB_SERIAL_OPT: serial port, e.g., "-serial mon:stdio" QB_TCPSERIAL_OPT: tcp serial port option, e.g., " -device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon" Note, runqemu will replace "@PORT@" with the port number which is used. Usage: IMAGE_CLASSES += "qemuboot" See "runqemu help" for more info // Robert On 10/14/2016 09:48 AM, Paul Eggleton wrote: Hi folks, We need some info for the migration section of the 2.2 manual about what the user needs to do to adapt to the new python-based runqemu. Robert / Joshua, can one of you please write something short that explains what users need to do (i.e. changes to the metadata for BSPs, or any other changes in operation)? It doesn't need to be polished, Scott Rifenbark will take care of that. Just replying to this email with Scott on CC should be sufficient. Thanks, Paul -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] taskhash mismatch
On Sun, Oct 02, 2016 at 10:34:22AM -0400, Trevor Woerner wrote: > Hi, > > For the last week or so my raspberry pi builds have been failing with: > > ERROR: core-image-minimal-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch > 2920e557ac3a011d5679a52590cb664d versus a47bfc12fdfa29c58fe72cf8e0a28e91 for > /z/raspi2/poky/meta/recipes-core/images/core-image-minimal.bb.do_image_rpi_sdimg > ERROR: Taskhash mismatch 2920e557ac3a011d5679a52590cb664d versus > a47bfc12fdfa29c58fe72cf8e0a28e91 for > /z/raspi2/poky/meta/recipes-core/images/core-image-minimal.bb.do_image_rpi_sdimg > > This is with both poky and oe+bitbake, master branches all around, and fully > up-to-date. Before sending this email I pulled yet again and re-tested just to > confirm. > > Poky: > > Build Configuration: > BB_VERSION= "1.31.1" > BUILD_SYS = "x86_64-linux" > NATIVELSBSTRING = "SUSELINUX-42.1" > TARGET_SYS= "arm-poky-linux-gnueabi" > MACHINE = "raspberrypi" > DISTRO= "poky" > DISTRO_VERSION= "2.1+snapshot-20161002" > TUNE_FEATURES = "arm armv6 vfp arm1176jzfs callconvention-hard" > TARGET_FPU= "hard" > meta > meta-poky = "master:3a73fe0efcb7aeefcca7011bba887caad03d4d03" > meta-raspberrypi = "master:4817e2c087097c02755d6309304878e42cf61d3c" > > OE + bitbake: > > Build Configuration: > BB_VERSION= "1.31.1" > BUILD_SYS = "x86_64-linux" > NATIVELSBSTRING = "SUSELINUX-42.1" > TARGET_SYS= "arm-oe-linux-gnueabi" > MACHINE = "raspberrypi" > DISTRO= "nodistro" > DISTRO_VERSION= "nodistro.0" > TUNE_FEATURES = "arm armv6 vfp arm1176jzfs callconvention-hard" > TARGET_FPU= "hard" > meta = "master:21cc2a3f63ea260dbf6b50e2fd4dd50cacdd9935" > meta-raspberrypi = "master:4817e2c087097c02755d6309304878e42cf61d3c" > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto I know I'm kinda late to the party but just wanted to say that this was fixed in master. Cheers! -- Andrei Gherzan signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-autobuilder][PATCH] PublishArtifacts.py: deal only with built toolchains, cp also md5 and manifests
On Thu, 2016-10-13 at 17:38 -0500, gm...@reliableembeddedsystems.com wrote: > Hi, > > On 2016-10-13 16:29, Lock, Joshua G wrote: > > > > Can you help me understand why you needed to create this patch? > > > > We've run into some issues recently where toolchains we expected to > > be > > built weren't and the PublishArtifacts buildstep failing because > > they're missing is useful. With this change we'll no longer get > > that, > > right? > > Yes that's right (and not intended). > > I would hope that you'll be able to detect such kind of problems > before > the PublishArtifacts buildstep because there should be some error in > previous steps. The toolchain did not build! Indeed, but software is buggy. This happened very recently on the public builders: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10275 Toolchains *were* being built but they were being unstaged from the deploy directory by an unfortunate bug. We had errors logged due to failing cp the buildstep didn't fail. > I made this patch because I just want to build a 64 bit toolchain as > opposed to both (like I used to do with some older version of Y-AB) > and > don't want the PublishArtifacts step to fail just because there is > no > 32-bit toolchain. There is no 32 bit toolchain on purpose. > > As a bonus the patch also copies md5sums and friends over and not > just > the .sh files. This is a reasonable goal, but something I'd rather see addressed in the proposed PublishArtifacts rewrite. As we're trying to release morty right now I'd like to avoid changes to the AB behaviour until after the release. Regards, Joshua -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fwd: Failed to build image, output error "ERROR: Worker process (11579) exited unexpectedly (-9), shutting down..."
Hi ALL: I am an software engineer in Askey. I have one question about building the apq-8053 device image. The main question is that I can not build well. Below is the error messages which show unexpected shutdown. I have studied from the web site and google and found the following links shows that https://bugzilla.yoctoproject.org/show_bug.cgi?id=6570 https://wiki.yoctoproject.org/wiki/WW35_-_2014-08-26_-_Weekly_-_1.7_M3 yocto seems provide an updated version and has fix this kind of issue. So how can I get the updated one for fixing this problem ?Why this happened ? Does it relate to the workstation hardware requirement? How Can I fix this problems ? What Information should I provide for the judgement about this issue ? paultsai@paultsai-VirtualBox:~/poky/build$ build-8053-image WARNING: Unable to chmod TMPDIR: [Errno 1] Operation not permitted: '/home/paultsai/poky/build/tmp-glibc' WARNING: Getting checksum for lib32-subsystem-ramdump SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for subsystem-ramdump SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for llvm-arm-toolchain-native SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for lib32-mcm-core SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for mcm-core SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for lib32-loc-mcm-test-shim SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for loc-mcm-test-shim SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for lib32-loc-mcm-qmi-test-shim SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for loc-mcm-qmi-test-shim SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for lib32-loc-mcm-type-conv SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for loc-mcm-type-conv SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for lib32-mcmlocserver SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for mcmlocserver SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for lib32-loc-base-util SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for loc-base-util SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for lib32-loc-mq-client SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for loc-mq-client SRC_URI entry : file not found except in DL_DIR WARNING: Unable to get checksum for lib32-glesproto SRC_URI entry include: file could not be found WARNING: Unable to get checksum for glesproto SRC_URI entry include: file could not be found WARNING: Getting checksum for lib32-mm-video-oss SRC_URI entry mm-video-oss: file not found except in DL_DIR WARNING: Getting checksum for mm-video-oss SRC_URI entry mm-video-oss: file not found except in DL_DIR WARNING: Unable to get checksum for lib32-libtbm-msm SRC_URI entry libtbm-msm: file could not be found WARNING: Unable to get checksum for libtbm-msm SRC_URI entry libtbm-msm: file could not be found WARNING: Unable to get checksum for lib32-libtbm SRC_URI entry libtbm: file could not be found WARNING: Unable to get checksum for libtbm SRC_URI entry libtbm: file could not be found WARNING: Unable to get checksum for lib32-start-scripts-find-recovery-partitions SRC_URI entry find_recovery_partitions.sh: file could not be found WARNING: Unable to get checksum for start-scripts-find-recovery-partitions SRC_URI entry find_recovery_partitions.sh: file could not be found WARNING: Unable to get checksum for lib32-msm7k SRC_URI entry msm7k: file could not be found WARNING: Unable to get checksum for msm7k SRC_URI entry msm7k: file could not be found WARNING: Unable to get checksum for lib32-dlog SRC_URI entry dlog: file could not be found WARNING: Unable to get checksum for dlog SRC_URI entry dlog: file could not be found WARNING: Unable to get checksum for lib32-iptables SRC_URI entry types.h-add-defines-that-are-required-for-if_packet.patch: file could not be found WARNING: Unable to get checksum for lib32-webserver SRC_URI entry webserver: file could not be found WARNING: Unable to get checksum for webserver SRC_URI entry webserver: file could not be found WARNING: Unable to get checksum for lib32-mm-image-codec SRC_URI entry mm-image-codec: file could not be found WARNING: Unable to get checksum for mm-image-codec SRC_URI entry mm-image-codec: file could not be found WARNING: Getting checksum for yaffs2-utils-native SRC_URI entry : file not found except in DL_DIR WARNING: Unable to get checksum for lib32-utils-lib SRC_URI entry utils: file could not be found WARNING: Unable to get checksum for utils-lib SRC_URI entry utils: file could not be found WARNING: Getting checksum for fsconfig-native SRC_URI entry : file not found except in DL_DIR WARNING: Getting checksum for fsconfig SRC_URI entry : file not found
Re: [yocto] [yocto-autobuilder][PATCH] PublishArtifacts.py: deal only with built toolchains, cp also md5 and manifests
Hi, On 2016-10-14 04:27, Joshua Lock wrote: This is a reasonable goal, but something I'd rather see addressed in the proposed PublishArtifacts rewrite. As we're trying to release morty right now I'd like to avoid changes to the AB behaviour until after the release. I'm absolutely happy with this and eagerly waiting for morty. Please keep me updated so, as my time permits, I can test the new Y-AB version. Regards, Joshua Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] bluez5: correctly append brcm43438 service
On Tue, Oct 04, 2016 at 12:51:34PM +0300, Samuli Piippo wrote:
> Cannot use += operator together with machine override.
>
> Signed-off-by: Samuli Piippo
> ---
> recipes-connectivity/bluez5/bluez5_%.bbappend | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/recipes-connectivity/bluez5/bluez5_%.bbappend
> b/recipes-connectivity/bluez5/bluez5_%.bbappend
> index 89798a4..956d776 100644
> --- a/recipes-connectivity/bluez5/bluez5_%.bbappend
> +++ b/recipes-connectivity/bluez5/bluez5_%.bbappend
> @@ -23,4 +23,4 @@ FILES_${PN}_append_raspberrypi3 = " \
> /lib/firmware/brcm/BCM43430A1.hcd \
> "
>
> -SYSTEMD_SERVICE_${PN}_raspberrypi3 += "brcm43438.service"
> +SYSTEMD_SERVICE_${PN}_append_raspberrypi3 = " brcm43438.service"
> --
> 1.9.1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
Megred to master. Thanks, Samuli.
--
Andrei Gherzan
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] failed to copy the final ***rootfs.rpi-sdimg image file
On Sat, Oct 01, 2016 at 01:58:49PM +, Karim ATIKI wrote:
> hi,
>
>
> I'm building a custom core-image-x11 for my raspberrypi3 board, with poky
> krogoth.
>
> In the very last steps:
>
>
> ERROR: core-image-x11-1.0-r0 do_image_rpi_sdimg: Function failed:
> do_image_rpi_sdimg (log file is located at
> /home/kai/yocto/build-rpi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-x11/1.0-r0/temp/log.do_image_rpi_sdimg.16110)
>
> ERROR: Logfile of failure stored in:
> /home/kai/yocto/build-rpi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-x11/1.0-r0/temp/log.do_image_rpi_sdimg.16110
>
> Log data follows:
> | DEBUG: Executing python function set_image_size
> | DEBUG: Python function set_image_size finished
> | DEBUG: Executing shell function do_image_rpi_sdimg
> | Creating filesystem with Boot partition 40960 KiB and RootFS 430080 KiB
>
> | dd: failed to open
> '/core-image-x11-raspberrypi3-20161001194728.rootfs.rpi-sdimg': Permission
> denied
>
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_image_rpi_sdimg (log file is located at
> /home/kai/yocto/build-rpi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-x11/1.0-r0/temp/log.do_image_rpi_sdimg.16110)
> ERROR: Task 16
> (/home/kai/yocto/poky-krogoth/meta/recipes-graphics/images/core-image-x11.bb,
> do_image_rpi_sdimg) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 4771 tasks of which 4770 didn't need to be
> rerun and 1 failed.
> No currently running tasks (4367 of 4773)
>
>
>
> It looks like it tries to create the image in the path:
> /core-image-x11-raspberrypi3-20161001194728.rootfs.rpi-sdimg': Permission
> denied
>
>
> I looked into the bbclass, and at first glance I'd say that the respective
> path is "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.rpi-sdimg"
>
>
> So ${IMGDEPLOYDIR} seems to be empty.
>
>
> I haven't found any reference to IMGDEPLOYDIR elsewhere.
>
>
> Weird.
>
>
> Karim
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
This should be fixed now by using krogoth meta-rpi branch with the poky
krogoth branch. Otherwise just use both masters and it should work as
well.
--
Andrei Gherzan
signature.asc
Description: PGP signature
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] taskhash mismatch
On Fri, Oct 14, 2016 at 5:25 AM, Andrei Gherzan wrote: > I know I'm kinda late to the party but just wanted to say that this was > fixed in master. Cheers! Excellent. I just tried 3 builds in a row and they all succeeded! Thanks for the update. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] taskhash mismatch
On Fri, Oct 14, 2016 at 08:50:05AM -0400, Trevor Woerner wrote: > On Fri, Oct 14, 2016 at 5:25 AM, Andrei Gherzan wrote: > > I know I'm kinda late to the party but just wanted to say that this was > > fixed in master. Cheers! > > Excellent. I just tried 3 builds in a row and they all succeeded! > > Thanks for the update. Great to hear this. Enjoy! -- Andrei Gherzan signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] failed to copy the final ***rootfs.rpi-sdimg image file
Great! Thanks!
Sent from my WIKO RAINBOW LITE 4GLe 14 oct. 2016 14:41, Andrei Gherzan
a écrit :
>
> On Sat, Oct 01, 2016 at 01:58:49PM +, Karim ATIKI wrote:
> > hi,
> >
> >
> > I'm building a custom core-image-x11 for my raspberrypi3 board, with poky
> > krogoth.
> >
> > In the very last steps:
> >
> >
> > ERROR: core-image-x11-1.0-r0 do_image_rpi_sdimg: Function failed:
> > do_image_rpi_sdimg (log file is located at
> > /home/kai/yocto/build-rpi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-x11/1.0-r0/temp/log.do_image_rpi_sdimg.16110)
> >
> >
> > ERROR: Logfile of failure stored in:
> > /home/kai/yocto/build-rpi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-x11/1.0-r0/temp/log.do_image_rpi_sdimg.16110
> >
> >
> > Log data follows:
> > | DEBUG: Executing python function set_image_size
> > | DEBUG: Python function set_image_size finished
> > | DEBUG: Executing shell function do_image_rpi_sdimg
> > | Creating filesystem with Boot partition 40960 KiB and RootFS 430080 KiB
> >
> > | dd: failed to open
> > '/core-image-x11-raspberrypi3-20161001194728.rootfs.rpi-sdimg': Permission
> > denied
> >
> > | WARNING: exit code 1 from a shell command.
> > | ERROR: Function failed: do_image_rpi_sdimg (log file is located at
> > /home/kai/yocto/build-rpi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-x11/1.0-r0/temp/log.do_image_rpi_sdimg.16110)
> >
> > ERROR: Task 16
> > (/home/kai/yocto/poky-krogoth/meta/recipes-graphics/images/core-image-x11.bb,
> > do_image_rpi_sdimg) failed with exit code '1'
> > NOTE: Tasks Summary: Attempted 4771 tasks of which 4770 didn't need to be
> > rerun and 1 failed.
> > No currently running tasks (4367 of 4773)
> >
> >
> >
> > It looks like it tries to create the image in the path:
> > /core-image-x11-raspberrypi3-20161001194728.rootfs.rpi-sdimg': Permission
> > denied
> >
> >
> > I looked into the bbclass, and at first glance I'd say that the respective
> > path is "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.rpi-sdimg"
> >
> >
> > So ${IMGDEPLOYDIR} seems to be empty.
> >
> >
> > I haven't found any reference to IMGDEPLOYDIR elsewhere.
> >
> >
> > Weird.
> >
> >
> > Karim
> >
> >
>
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
> This should be fixed now by using krogoth meta-rpi branch with the poky
> krogoth branch. Otherwise just use both masters and it should work as
> well.
>
> --
> Andrei Gherzan
>
> --
> ___
> 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] Big endian ARM machine with NEON wanted
On Fri, Oct 14, 2016 at 07:41:13AM +0200, Mike Looijmans wrote: > On 13-10-16 19:20, Andreas Müller wrote: > > > >Does anybody know a big endian and common machine supporting NEON? I > >would need one for testing my port of portaudio. > > > Most ARM systems can run in both big-endian and little-endian modes. > Somewhere early during boot this choice is being made. > > Having said that, since big-endian machines are getting rare, there's very > little support for big-endian ARM systems. Most (if not all) boards can run > big-endian, but software support is usually lacking, in particular in the > bootloader parts where this matters. > > If it's just for testing some software, maybe you can use a QEMU machine? Well from what I was able to find, it seems ARMv7 systems can only run BE8 mode, while ARMv5 and older had BE32 mode, and ARMv6 had both options. Qemu seems to support BE8 mode when emulating ARMv7 (at least if you have a recent enough version). -- Len Sorensen -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Two pythons
I just moved my project from Fido to Krogoth and now I have two pythons (2.7 and 3). This bumps the size of my image by approximately 25%. What would be the most reasonable way to get back to just one python? Ideally I'd like a magical setting to get rid of python3 because there is no custom code for that one but I suppose with enough work I could get all of the python2 code working with python3. Michael -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] Master doesn't seem to be building right...
It's boggling on the sd card image build. Attached is the console output from
the build (Don't need the log, this one's clear from the build fail output.)
and a dump of the directory structures in tmp/deploy/images/raspberrypi2 from
my setup.
It's choking on trying to put the overlays onto the sd card image:
/home/frank/git_repos/guardhat/build/tmp/deploy/images/raspberrypi2/Image-hifiberry-amp.dtbo:
No such file or directory
| WARNING:
/home/frank/git_repos/guardhat/build/tmp/work/raspberrypi2-poky-linux-gnueabi/gh-base-image/1.0-r0/temp/run.do_image_rpi_sdimg.26079:1
exit 1 from 'mcopy -i
/home/frank/git_repos/guardhat/build/tmp/work/raspberrypi2-poky-linux-gnueabi/gh-base-image/1.0-r0/boot.img
-s
/home/frank/git_repos/guardhat/build/tmp/deploy/images/raspberrypi2/Image-${DTB_BASE_NAME}.${DTB_EXT}
::overlays/${DTB_BASE_NAME}.${DTB_EXT}'
Directory path:
4 -rw-r--r-- 2 frank frank 779 Oct 13 20:27
/home/frank/git_repos/guardhat/build/tmp/deploy/images/raspberrypi2/Image-1-4.4.23+git0+c2a1d97553-r0-hifiberry-amp.dtbo-20161014012231.dtb
So, the backing file seems to be there...but...
4 lrwxrwxrwx 1 frank frank 71 Oct 13 20:45
/home/frank/git_repos/guardhat/build/tmp/deploy/images/raspberrypi2/Image-hifiberry-amp.dtbo.dtb
-> Image-1-4.4.23+git0+c2a1d97553-r0-hifiberry-amp.dtbo-20161014012231.dtb
Heh... Something's not QUITE right there. The packager is looking for .dtbo's
and we're symlinking .dtb's...I'm looking through the path trying to
understand how it's setting the 'latest-build' symlinks, but if someone
actually has a hint for me, it'd be appreciated. :-D
Frank Earl
Frank Earl
Legal Disclaimer:
The information contained in this message may be privileged and confidential.
It is intended to be read only by the individual or entity to whom it is
addressed or by their designee. If the reader of this message is not the
intended recipient, you are on notice that any distribution of this message, in
any form, is strictly prohibited. If you have received this message in error,
please immediately notify the sender and delete or destroy any copy of this
message!Loading cache...done.
Loaded 2741 entries from dependency cache.
WARNING: No recipes available for:
/home/frank/git_repos/guardhat/build/../meta-gh/recipes-bsp/u-boot/u-boot-ti-staging_2015.07.bbappend
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION= "1.30.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE = "raspberrypi2"
DISTRO= "poky"
DISTRO_VERSION= "2.1.1"
TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard
cortexa7"
TARGET_FPU= "hard"
meta
meta-poky
meta-yocto-bsp= "krogoth:e93596fe74927e2e2f4dd7f671994ccb9744cff8"
meta-linaro-toolchain = "krogoth:85faf6c6824597e7fd9e2d35fc9d8da2e9f90bc7"
meta-oe
meta-filesystems
meta-networking
meta-multimedia
meta-initramfs
meta-systemd
meta-python = "krogoth:851a064b53dca3b14dd33eaaaca9573b1a36bf0e"
meta-telephony= "HEAD:8cf5a67850adf270bc2fdb4c0ed708b0ba037670"
meta-gh = "master:12dc12456e7f6f486ca2815603c5f21f74c2d2c2"
meta-ti = "master:6cb779a6ba1b0693f6bf82777e1a333effe6fca5"
meta-raspberrypi = "master:05be947a31df873405cdd70ada210c9f7f7b132f"
NOTE: Preparing RunQueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 3034 of 3320 (ID: 16,
/home/frank/git_repos/guardhat/build/../meta-gh/recipes-core/images/gh-base-image.bb,
do_image_rpi_sdimg)
NOTE: recipe gh-base-image-1.0-r0: task do_image_rpi_sdimg: Started
Log data follows:
| DEBUG: Executing python function set_image_size
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_rpi_sdimg
| Creating filesystem with Boot partition 40960 KiB and RootFS 253952 KiB
| 0+0 records in
| 0+0 records out
| 0 bytes (0 B) copied, 1.125e-05 s, 0.0 kB/s
| Model: (file)
| Disk /gh-base-image-raspberrypi2-20161014141945.rootfs.rpi-sdimg: 306MB
| Sector size (logical/physical): 512B/512B
| Partition Table: msdos
| Disk Flags:
|
| Number Start End SizeType File system Flags
| 1 4194kB 46.1MB 41.9MB primary boot, lba
| 2 46.1MB 306MB 260MB primary
|
| mkfs.fat: warning - lowercase labels might not work properly with DOS or
Windows
| mkfs.fat 3.0.28 (2015-05-16)
|
/home/frank/git_repos/guardhat/build/tmp/deploy/images/raspberrypi2/Image-hifiberry-amp.dtbo:
No such file or directory
| WARNING:
/home/frank/git_repos/guardhat/build/tmp/work/raspberrypi2-poky-linux-gnueabi/gh-base-image/1.0-r0/temp/run.do_image_rpi_sdimg.26079:1
exit 1 from 'mcopy -i
/home/frank/git_repos/guardhat/build/tmp/work/raspberrypi2-poky-linux-gnueabi/gh-base-image/1.0-r0/boot.img
-s
/home/frank/git_repos/guardhat/build/tmp/deploy/images/raspberrypi2/Im
[yocto] [meta-raspberrypi] build rpi-test-image for raspberrypi3
Hello,
I am trying to build the rpi-test-image for a raspberrypi3 using the Poky and
raspberrypi master branches.
Below are the layers I include in my 'bblayers.conf':
${BSPDIR}/master/poky/meta \
${BSPDIR}/master/poky/meta-poky \
${BSPDIR}/master/poky/meta-yocto-bsp \
${BSPDIR}/master/meta-openembedded/meta-oe \
${BSPDIR}/master/meta-openembedded/meta-webserver \
${BSPDIR}/master/meta-openembedded/meta-networking \
${BSPDIR}/master/meta-openembedded/meta-multimedia \
${BSPDIR}/master/meta-openembedded/meta-python \
${BSPDIR}/master/meta-raspberrypi \
And I add the following to my 'local.conf':
MACHINE ??= "raspberrypi3"
LICENSE_FLAGS_WHITELIST = "commercial"
However, when I launch 'bitbake rpi-test-image', I get the following error:
Parsing recipes: 100%
||
Time: 0:00:53
Parsing of 1961 .bb files complete (0 cached, 1961 parsed). 2647 targets, 134
skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'samba' (but
/home/seb/workspace/Yocto/meta_sources/master/meta-raspberrypi/recipes-multimedia/omxplayer/omxplayer_git.bb
DEPENDS on or otherwise requires it)
ERROR: samba was skipped: Recipe is blacklisted: BROKEN: fails to build with
new binutils-2.27
NOTE: Runtime target 'omxplayer' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['omxplayer', 'samba']
NOTE: Runtime target 'packagegroup-rpi-test' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['packagegroup-rpi-test',
'omxplayer', 'samba']
ERROR: Required build target 'rpi-test-image' has no buildable providers.
Missing or unbuildable dependency chain was: ['rpi-test-image',
'packagegroup-rpi-test', 'omxplayer', 'samba']
Would someone know what I am missing? When I use the Jethro branches for a
rasperrypi2, I have no problem.
Thanks in advance
Seb --
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] building uclibc based image for arm
Hi, I am trying build uclibc based image. But getting following error. Note: - I am using yocto-1.7.2 - Set TCLIBC ?= "uclibc" in distro/defaultsetup.conf - Building for arm # bitbake core-image-minimal NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: Function failed: do_install (log file is located at /home/hgovind/projects/temp/test-sdk/ap-sdk/yp_ap/tmp/work/armv7a-vfp-neon-poky-linux-uclibceabi/glibc-locale/2.20-r0/temp/log.do_install.29445) ERROR: Logfile of failure stored in: /home/hgovind/projects/temp/test-sdk/ap-sdk/yp_ap/tmp/work/armv7a-vfp-neon-poky-linux-uclibceabi/glibc-locale/2.20-r0/temp/log.do_install.29445 Log data follows: | DEBUG: Executing shell function do_install | ls: cannot access /home/hgovind/projects/temp/test-sdk/ap-sdk/yp_ap/tmp/sysroots/ap3k-lxc/usr/include/glibc-locale-internal-armv7a-vfp-neon-poky-linux-uclibceabi//usr/bin: No such file or directory | ls: cannot access /home/hgovind/projects/temp/test-sdk/ap-sdk/yp_ap/tmp/sysroots/ap3k-lxc/usr/include/glibc-locale-internal-armv7a-vfp-neon-poky-linux-uclibceabi//usr/lib/locale: No such file or directory | cp: cannot stat '/home/hgovind/projects/temp/test-sdk/ap-sdk/yp_ap/tmp/sysroots/ap3k-lxc/usr/include/glibc-locale-internal-armv7a-vfp-neon-poky-linux-uclibceabi/SUPPORTED': No such file or directory | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_install (log file is located at /home/hgovind/projects/temp/test-sdk/ap-sdk/yp_ap/tmp/work/armv7a-vfp-neon-poky-linux-uclibceabi/glibc-locale/2.20-r0/temp/log.do_install.29445) ERROR: Task 1094 (/home/hgovind/projects/temp/test-sdk/ap-sdk/sys/yocto-1.7/poky-dizzy-12.0.2/meta/recipes-core/glibc/glibc-locale_2.20.bb, do_install) failed with exit code '1' NOTE: Tasks Summary: Attempted 780 tasks of which 703 didn't need to be rerun and 1 failed. Waiting for 0 running tasks to finish: Summary: 1 task failed: /home/hgovind/projects/temp/test-sdk/ap-sdk/sys/yocto-1.7/poky-dizzy-12.0.2/meta/recipes-core/glibc/glibc-locale_2.20.bb, do_install Summary: There was 1 ERROR message shown, returning a non-zero exit code. Could you please let me know if I am following correct steps to create uclibc based image? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto recipe license
Hello, it seems that license.manifest file describes application/lib/etc. source code license, but what about Yocto recipe license itself ? So what is the license of a Yocto recipe ? How to know it ? If a Yocto recipe is GPL2, and we extend (*.bbappend) this recipe, does contamination effect applies to the extented recipe ? Thanks for your help, contrib -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Two pythons
On 12 October 2016 at 18:58, Michael Callahan wrote: > I just moved my project from Fido to Krogoth and now I have two > pythons (2.7 and 3). This bumps the size of my image by approximately > 25%. What would be the most reasonable way to get back to just one > python? Ideally I'd like a magical setting to get rid of python3 > because there is no custom code for that one but I suppose with enough > work I could get all of the python2 code working with python3. > Sadly you can't have a magic option to flip from one to the other as code isn't compatible. In general master has moved to be 99% Py3 - with smartpm being the only major python2 recipe left - but I thought Krogoth was still Py2 by default so shouldn't be in your image by default. I suggest you use the usual tools to find out why python2 and python3 are in your images, and see what you can change to have just one. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Two pythons
On Fri, Oct 14, 2016 at 8:54 AM, Burton, Ross wrote: > On 12 October 2016 at 18:58, Michael Callahan > wrote: > >> I just moved my project from Fido to Krogoth and now I have two >> pythons (2.7 and 3). This bumps the size of my image by approximately >> 25%. What would be the most reasonable way to get back to just one >> python? Ideally I'd like a magical setting to get rid of python3 >> because there is no custom code for that one but I suppose with enough >> work I could get all of the python2 code working with python3. >> > > Sadly you can't have a magic option to flip from one to the other as code > isn't compatible. In general master has moved to be 99% Py3 - with smartpm > being the only major python2 recipe left - but I thought Krogoth was still > Py2 by default so shouldn't be in your image by default. > > I suggest you use the usual tools to find out why python2 and python3 are > in your images, and see what you can change to have just one. > Yeah, as Ross says, the usual tools are best there. There are some things you can do to avoid the python dependency for certain recipes, but it has to be dealt with on a case by case basis, and of course depends on what your image is pulling in. For example, https://github.com/openembedded/openembedded-core/compare/master...kergoth:systemtap-python3 splits out systemtap-dtrace into a separate recipe which is pulled in via RRECOMMENDS, so I can use BAD_RECOMMENDATIONS to exclude it for images that don’t need it (dtrace is the only thing in systemtap that needs python3). https://github.com/openembedded/meta-openembedded/compare/master...kergoth:lirc-python-3 does the same for lirc. -- 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] [meta-mingw] Patch needed to let linker find lto plugin
Could you please elaborate on what do you mean by "built it as-is". I tested the meta layer with some cases I considered typical or most common. (I think I enumerated them in my original message). Apparently I missed one. Thanks Juro > -Original Message- > From: Winfried [mailto:winfried_...@xmsnet.nl] > Sent: Friday, October 14, 2016 10:26 AM > To: yocto@yoctoproject.org > Cc: Bystricky, Juro > Subject: [meta-mingw] Patch needed to let linker find lto plugin > > Recently the meta-mingw layer was updated to krogoth by Juro Bystricky. > Thanks ! > However when I build it as-is, the linker fails because it can't load > the lto plugin. > > After applying commit a06e473590207f72b11d273a09de2c8a889c381e from > meta-mingw-contrib (by Mark Hatle), the error disappeared. > > See: > http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw- > contrib/commit/?h=mgh/jetho/meta- > mingw&id=a06e473590207f72b11d273a09de2c8a889c381e > > regards, > W. Dobbe -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-mingw] Patch needed to let linker find lto plugin
Recently the meta-mingw layer was updated to krogoth by Juro Bystricky. Thanks ! However when I build it as-is, the linker fails because it can't load the lto plugin. After applying commit a06e473590207f72b11d273a09de2c8a889c381e from meta-mingw-contrib (by Mark Hatle), the error disappeared. See: http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-contrib/commit/?h=mgh/jetho/meta-mingw&id=a06e473590207f72b11d273a09de2c8a889c381e I think this patch needs to be applied also to the meta-mingw main repository. regards, W. Dobbe -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mingw] Patch needed to let linker find lto plugin
Hi Juro,
My Yocto environment is for the Congatec QMX6 SoM that is built around a
quadcore i.MX6.
I use the Yocto layers from the Congatec repository
(https://git.congatec.com/public), which includes the meta-fsl-arm and
meta-fsl-arm-extra layers.
My bblayers.conf is:
BBLAYERS = " \
${BSPDIR}/sources/poky/meta \
${BSPDIR}/sources/poky/meta-poky \
\
${BSPDIR}/sources/meta-openembedded/meta-oe \
${BSPDIR}/sources/meta-openembedded/meta-multimedia \
${BSPDIR}/sources/meta-openembedded/meta-python \
${BSPDIR}/sources/meta-openembedded/meta-networking \
\
${BSPDIR}/sources/meta-fsl-arm \
${BSPDIR}/sources/meta-fsl-arm-extra \
${BSPDIR}/sources/meta-fsl-demos \
\
${BSPDIR}/sources/meta-mingw \
\
${BSPDIR}/sources/meta-peek \
${BSPDIR}/sources/meta-peek-ecng \
"
The image I normally build (peek-image-ecng-acu-default) is based upon
the core-image-full-cmdline image.
I built the MinGW SDK by adding SDKMACHINE="x86_64-mingw32" to my
local.conf and typing the command "bitbake peek-image-ecng-acu-default
-c populate_sdk".
I attended the Yocto developer day in Berlin last week. When I showed
the MinGW linker LTO plugin error to Mark Hatle, he suggested applying
his patch.
best regards,
Winfried
Bystricky, Juro schreef op 14.10.2016 20:04:
Could you please elaborate on what do you mean by "built it as-is".
I tested the meta layer with some cases I considered typical
or most common. (I think I enumerated them in my original
message). Apparently I missed one.
Thanks
Juro
-Original Message-
From: Winfried [mailto:winfried_...@xmsnet.nl]
Sent: Friday, October 14, 2016 10:26 AM
To: yocto@yoctoproject.org
Cc: Bystricky, Juro
Subject: [meta-mingw] Patch needed to let linker find lto plugin
Recently the meta-mingw layer was updated to krogoth by Juro
Bystricky.
Thanks !
However when I build it as-is, the linker fails because it can't load
the lto plugin.
After applying commit a06e473590207f72b11d273a09de2c8a889c381e from
meta-mingw-contrib (by Mark Hatle), the error disappeared.
See:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-
contrib/commit/?h=mgh/jetho/meta-
mingw&id=a06e473590207f72b11d273a09de2c8a889c381e
regards,
W. Dobbe
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mingw] Patch needed to let linker find lto plugin
Thanks. I will re-run some basic tests again and
send the patch by Mark Hatle (applied to meta-mingw/krogoth) to the mailing
list.
> -Original Message-
> From: winfried.do...@xmsnet.nl [mailto:winfried.do...@xmsnet.nl]
> Sent: Friday, October 14, 2016 11:35 AM
> To: Bystricky, Juro ; yocto@yoctoproject.org
> Cc: Hatle, Mark G (Wind River)
> Subject: RE: [meta-mingw] Patch needed to let linker find lto plugin
>
> Hi Juro,
>
> My Yocto environment is for the Congatec QMX6 SoM that is built around a
> quadcore i.MX6.
> I use the Yocto layers from the Congatec repository
> (https://git.congatec.com/public), which includes the meta-fsl-arm and
> meta-fsl-arm-extra layers.
>
> My bblayers.conf is:
>
> BBLAYERS = " \
>${BSPDIR}/sources/poky/meta \
>${BSPDIR}/sources/poky/meta-poky \
>\
>${BSPDIR}/sources/meta-openembedded/meta-oe \
>${BSPDIR}/sources/meta-openembedded/meta-multimedia \
>${BSPDIR}/sources/meta-openembedded/meta-python \
>${BSPDIR}/sources/meta-openembedded/meta-networking \
>\
>${BSPDIR}/sources/meta-fsl-arm \
>${BSPDIR}/sources/meta-fsl-arm-extra \
>${BSPDIR}/sources/meta-fsl-demos \
>\
>${BSPDIR}/sources/meta-mingw \
>\
>${BSPDIR}/sources/meta-peek \
>${BSPDIR}/sources/meta-peek-ecng \
> "
>
> The image I normally build (peek-image-ecng-acu-default) is based upon
> the core-image-full-cmdline image.
>
> I built the MinGW SDK by adding SDKMACHINE="x86_64-mingw32" to my
> local.conf and typing the command "bitbake peek-image-ecng-acu-default
> -c populate_sdk".
>
> I attended the Yocto developer day in Berlin last week. When I showed
> the MinGW linker LTO plugin error to Mark Hatle, he suggested applying
> his patch.
>
> best regards,
>
> Winfried
>
>
> Bystricky, Juro schreef op 14.10.2016 20:04:
> > Could you please elaborate on what do you mean by "built it as-is".
> > I tested the meta layer with some cases I considered typical
> > or most common. (I think I enumerated them in my original
> > message). Apparently I missed one.
> >
> > Thanks
> >
> > Juro
> >
> >
> >> -Original Message-
> >> From: Winfried [mailto:winfried_...@xmsnet.nl]
> >> Sent: Friday, October 14, 2016 10:26 AM
> >> To: yocto@yoctoproject.org
> >> Cc: Bystricky, Juro
> >> Subject: [meta-mingw] Patch needed to let linker find lto plugin
> >>
> >> Recently the meta-mingw layer was updated to krogoth by Juro
> >> Bystricky.
> >> Thanks !
> >> However when I build it as-is, the linker fails because it can't load
> >> the lto plugin.
> >>
> >> After applying commit a06e473590207f72b11d273a09de2c8a889c381e from
> >> meta-mingw-contrib (by Mark Hatle), the error disappeared.
> >>
> >> See:
> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-
> >> contrib/commit/?h=mgh/jetho/meta-
> >> mingw&id=a06e473590207f72b11d273a09de2c8a889c381e
> >>
> >> regards,
> >> W. Dobbe
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
