Re: [yocto] resize2fs
Le 13 oct. 2016 08:44, "Peter Balazovic" a
écrit :
>
> Dears,
>
> I just build the yocto image and within local.conf I got
>
> IMAGE_INSTALL_append = "e2fsprogs"
First, you need an extra space when you use _append operator.
.
>
> but unfortunately I do not get resize2fs utility installed. I do not not
why?
Then if you look at the recipe each app is packaged separately so that you
can pick and choose only the one you need. So you need to include
e2fsprogs-resize2fs
> this how e2fsprogs_1.42.9.bb looks like
>
>
>
> require e2fsprogs.inc
>
>
> SRC_URI += "file://acinclude.m4 \
> file://remove.ldconfig.call.patch \
> file://fix-icache.patch \
> file://quiet-debugfs.patch \
>
file://0001-mke2fs-add-the-ability-to-copy-files-from-a-given-di.patch \
> file://0002-misc-create_inode.c-copy-files-recursively.patch \
> file://0003-misc-create_inode.c-create-special-file.patch \
> file://0004-misc-create_inode.c-create-symlink.patch \
> file://0005-misc-create_inode.c-copy-regular-file.patch \
> file://0006-misc-create_inode.c-create-directory.patch \
>
file://0007-misc-create_inode.c-set-owner-mode-time-for-the-inod.patch \
> file://0008-mke2fs.c-add-an-option-d-root-directory.patch \
> file://0009-misc-create_inode.c-handle-hardlinks.patch \
>
file://0010-debugfs-use-the-functions-in-misc-create_inode.c.patch \
>
file://0011-mke2fs.8.in-update-the-manual-for-the-d-option.patch \
> file://0012-Fix-musl-build-failures.patch \
> file://0001-e2fsprogs-fix-cross-compilation-problem.patch \
>
file://misc-mke2fs.c-return-error-when-failed-to-populate-fs.patch \
> file://cache_inode.patch \
> file://CVE-2015-0247.patch \
>
file://0001-libext2fs-fix-potential-buffer-overflow-in-closefs.patch \
> "
>
> SRC_URI[md5sum] = "3f8e41e63b432ba114b33f58674563f7"
> SRC_URI[sha256sum] =
"2f92ac06e92fa00f2ada3ee67dad012d74d685537527ad1241d82f2d041f2802"
>
> EXTRA_OECONF += "--libdir=${base_libdir} --sbindir=${base_sbindir}
--enable-elf-shlibs --disable-libuuid --disable-uuidd
--enable-verbose-makecmds"
> EXTRA_OECONF_darwin = "--libdir=${base_libdir} --sbindir=${base_sbindir}
--enable-bsd-shlibs"
>
> do_configure_prepend () {
> cp ${WORKDIR}/acinclude.m4 ${S}/
> }
>
> do_install () {
> oe_runmake 'DESTDIR=${D}' install
> oe_runmake 'DESTDIR=${D}' install-libs
> # We use blkid from util-linux now so remove from here
> rm -f ${D}${base_libdir}/libblkid*
> rm -rf ${D}${includedir}/blkid
> rm -f ${D}${base_libdir}/pkgconfig/blkid.pc
> rm -f ${D}${base_sbindir}/blkid
> rm -f ${D}${base_sbindir}/fsck
> rm -f ${D}${base_sbindir}/findfs
>
> # e2initrd_helper and the pkgconfig files belong in libdir
> if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
> install -d ${D}${libdir}
> mv ${D}${base_libdir}/e2initrd_helper ${D}${libdir}
> mv ${D}${base_libdir}/pkgconfig ${D}${libdir}
> fi
>
> oe_multilib_header ext2fs/ext2_types.h
> install -d ${D}${base_bindir}
> mv ${D}${bindir}/chattr ${D}${base_bindir}/chattr.e2fsprogs
>
> install -v -m 755 ${S}/contrib/populate-extfs.sh ${D}${base_sbindir}/
> }
>
> do_install_append_class-target() {
> # Clean host path in compile_et, mk_cmds
> sed -i -e "s,ET_DIR=\"${S}/lib/et\",ET_DIR=\"${datadir}/et\",g"
${D}${bindir}/compile_et
> sed -i -e "s,SS_DIR=\"${S}/lib/ss\",SS_DIR=\"${datadir}/ss\",g"
${D}${bindir}/mk_cmds
> }
>
> RDEPENDS_e2fsprogs = "e2fsprogs-badblocks"
> RRECOMMENDS_e2fsprogs = "e2fsprogs-mke2fs e2fsprogs-e2fsck"
>
> PACKAGES =+ "e2fsprogs-e2fsck e2fsprogs-mke2fs e2fsprogs-tune2fs
e2fsprogs-badblocks e2fsprogs-resize2fs"
> PACKAGES =+ "libcomerr libss libe2p libext2fs"
>
> FILES_e2fsprogs-resize2fs = "${base_sbindir}/resize2fs*"
> FILES_e2fsprogs-e2fsck = "${base_sbindir}/e2fsck
${base_sbindir}/fsck.ext*"
> FILES_e2fsprogs-mke2fs = "${base_sbindir}/mke2fs
${base_sbindir}/mkfs.ext* ${sysconfdir}/mke2fs.conf"
> FILES_e2fsprogs-tune2fs = "${base_sbindir}/tune2fs
${base_sbindir}/e2label"
> FILES_e2fsprogs-badblocks = "${base_sbindir}/badblocks"
> FILES_libcomerr = "${base_libdir}/libcom_err.so.*"
> FILES_libss = "${base_libdir}/libss.so.*"
> FILES_libe2p = "${base_libdir}/libe2p.so.*"
> FILES_libext2fs = "${libdir}/e2initrd_helper
${base_libdir}/libext2fs.so.*"
> FILES_${PN}-dev += "${datadir}/*/*.awk ${datadir}/*/*.sed
${base_libdir}/*.so"
>
> BBCLASSEXTEND = "native nativesdk"
>
> inherit update-alternatives
>
> ALTERNATIVE_${PN} = "chattr"
> ALTERNATIVE_PRIORITY = "100"
> ALTERNATIVE_LINK_NAME[chattr] = "${base_bindir}/chattr"
> ALTERNATIVE_TARGET[chattr] = "${base_bindir}/chattr.e2fsprogs"
>
>
> --
> ___
> 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] resize2fs
> First, you need an extra space when you use _append operator.
I got within my local.conf and building for big size SD card.
IMAGE_ROOTFS_EXTRA_SPACE = "25165824"
> So you need to include e2fsprogs-resize2fs
that's what I'm looking for - where to include ...
On Thu, Oct 13, 2016 at 8:49 AM, Nicolas Dechesne <
nicolas.deche...@linaro.org> wrote:
> Le 13 oct. 2016 08:44, "Peter Balazovic" a
> écrit :
> >
> > Dears,
> >
> > I just build the yocto image and within local.conf I got
> >
> > IMAGE_INSTALL_append = "e2fsprogs"
>
> First, you need an extra space when you use _append operator.
>
> .
> >
> > but unfortunately I do not get resize2fs utility installed. I do not not
> why?
>
> Then if you look at the recipe each app is packaged separately so that you
> can pick and choose only the one you need. So you need to include
> e2fsprogs-resize2fs
>
> > this how e2fsprogs_1.42.9.bb looks like
> >
> >
> >
> > require e2fsprogs.inc
> >
> >
> > SRC_URI += "file://acinclude.m4 \
> > file://remove.ldconfig.call.patch \
> > file://fix-icache.patch \
> > file://quiet-debugfs.patch \
> >
> > file://0001-mke2fs-add-the-ability-to-copy-files-from-a-given-di.patch
> \
> > file://0002-misc-create_inode.c-copy-files-recursively.patch
> \
> > file://0003-misc-create_inode.c-create-special-file.patch \
> > file://0004-misc-create_inode.c-create-symlink.patch \
> > file://0005-misc-create_inode.c-copy-regular-file.patch \
> > file://0006-misc-create_inode.c-create-directory.patch \
> >
> > file://0007-misc-create_inode.c-set-owner-mode-time-for-the-inod.patch
> \
> > file://0008-mke2fs.c-add-an-option-d-root-directory.patch \
> > file://0009-misc-create_inode.c-handle-hardlinks.patch \
> >
> > file://0010-debugfs-use-the-functions-in-misc-create_inode.c.patch
> \
> > file://0011-mke2fs.8.in-update-the-manual-for-the-d-option.patch
> \
> > file://0012-Fix-musl-build-failures.patch \
> > file://0001-e2fsprogs-fix-cross-compilation-problem.patch \
> >
> > file://misc-mke2fs.c-return-error-when-failed-to-populate-fs.patch
> \
> > file://cache_inode.patch \
> > file://CVE-2015-0247.patch \
> >
> > file://0001-libext2fs-fix-potential-buffer-overflow-in-closefs.patch
> \
> > "
> >
> > SRC_URI[md5sum] = "3f8e41e63b432ba114b33f58674563f7"
> > SRC_URI[sha256sum] = "2f92ac06e92fa00f2ada3ee67dad01
> 2d74d685537527ad1241d82f2d041f2802"
> >
> > EXTRA_OECONF += "--libdir=${base_libdir} --sbindir=${base_sbindir}
> --enable-elf-shlibs --disable-libuuid --disable-uuidd
> --enable-verbose-makecmds"
> > EXTRA_OECONF_darwin = "--libdir=${base_libdir} --sbindir=${base_sbindir}
> --enable-bsd-shlibs"
> >
> > do_configure_prepend () {
> > cp ${WORKDIR}/acinclude.m4 ${S}/
> > }
> >
> > do_install () {
> > oe_runmake 'DESTDIR=${D}' install
> > oe_runmake 'DESTDIR=${D}' install-libs
> > # We use blkid from util-linux now so remove from here
> > rm -f ${D}${base_libdir}/libblkid*
> > rm -rf ${D}${includedir}/blkid
> > rm -f ${D}${base_libdir}/pkgconfig/blkid.pc
> > rm -f ${D}${base_sbindir}/blkid
> > rm -f ${D}${base_sbindir}/fsck
> > rm -f ${D}${base_sbindir}/findfs
> >
> > # e2initrd_helper and the pkgconfig files belong in libdir
> > if [ ! ${D}${libdir} -ef ${D}${base_libdir} ]; then
> > install -d ${D}${libdir}
> > mv ${D}${base_libdir}/e2initrd_helper ${D}${libdir}
> > mv ${D}${base_libdir}/pkgconfig ${D}${libdir}
> > fi
> >
> > oe_multilib_header ext2fs/ext2_types.h
> > install -d ${D}${base_bindir}
> > mv ${D}${bindir}/chattr ${D}${base_bindir}/chattr.e2fsprogs
> >
> > install -v -m 755 ${S}/contrib/populate-extfs.sh ${D}${base_sbindir}/
> > }
> >
> > do_install_append_class-target() {
> > # Clean host path in compile_et, mk_cmds
> > sed -i -e "s,ET_DIR=\"${S}/lib/et\",ET_DIR=\"${datadir}/et\",g"
> ${D}${bindir}/compile_et
> > sed -i -e "s,SS_DIR=\"${S}/lib/ss\",SS_DIR=\"${datadir}/ss\",g"
> ${D}${bindir}/mk_cmds
> > }
> >
> > RDEPENDS_e2fsprogs = "e2fsprogs-badblocks"
> > RRECOMMENDS_e2fsprogs = "e2fsprogs-mke2fs e2fsprogs-e2fsck"
> >
> > PACKAGES =+ "e2fsprogs-e2fsck e2fsprogs-mke2fs e2fsprogs-tune2fs
> e2fsprogs-badblocks e2fsprogs-resize2fs"
> > PACKAGES =+ "libcomerr libss libe2p libext2fs"
> >
> > FILES_e2fsprogs-resize2fs = "${base_sbindir}/resize2fs*"
> > FILES_e2fsprogs-e2fsck = "${base_sbindir}/e2fsck
> ${base_sbindir}/fsck.ext*"
> > FILES_e2fsprogs-mke2fs = "${base_sbindir}/mke2fs
> ${base_sbindir}/mkfs.ext* ${sysconfdir}/mke2fs.conf"
> > FILES_e2fsprogs-tune2fs = "${base_sbindir}/tune2fs
> ${base_sbindir}/e2label"
> > FILES_e2fsprogs-badblocks = "${base_sbindir}/badblocks"
> > FILES_libcomerr = "${base_libdir}/libcom_err.so.*"
> > FILES_libss = "${base_libdir}/libss.so.*"
> > FILES_libe2p = "${base_libdir}/libe2p.so.*"
> > FILES_libext2fs = "${libdir}/e2initrd_helper
> ${base_libdir}/libe
Re: [yocto] resize2fs
On Thu, Oct 13, 2016 at 9:03 AM, Peter Balazovic wrote: > > First, you need an extra space when you use _append operator. > I got within my local.conf and building for big size SD card. > > IMAGE_ROOTFS_EXTRA_SPACE = "25165824" > that's not what I meant, you need a leasding space char in the variable like IMAGE_INSTALL_append = " e2fsprogs-resize2fs" > > So you need to include e2fsprogs-resize2fs > > that's what I'm looking for - where to include ... > local.conf would work. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto - linaro's lava integration
Hi Mark,
thanks a lot for replying to my message. On the last few days I managed
to find the missing key of the puzzle on some lava slides on the
internet. In fact you can boot and test an image having the kernel and
fs separately.
here is the job description:
device_type: qemu
job_name: qemu-x86-test
timeouts:
job:
minutes: 6
action:
minutes: 2
priority: medium
visibility: public
context:
arch: i386
actions:
- deploy:
timeout:
minutes: 3
to: tmpfs
images:
kernel:
image_arg: -kernel {kernel} -append "console=ttyS0
root=/dev/vda rw"
url: file:///opt/image/kernel.bin
rootfs:
image_arg: -drive format=raw,file={rootfs},if=virtio
url: file:///opt/image/fs.ext4
os: debian
root_partition: 1
- boot:
method: qemu
timeout:
minutes: 2
media: tmpfs
prompts:
- "root@debian:"
auto_login:
login_prompt: "login:"
username: root
it is as you say, quite intuitive but i had some trouble finding the
proper description of this job definition. Now I am focus on how to set
up the integration process, how to submit the job after the building
process have been triggered in the git repo and so on.
Its actually easy once you find the pieces of information that you need.
Thanks again and let's see how it goes :P
Best,
Alfonso
On 12.10.2016 17:03, Mark Asselstine wrote:
On Monday, October 10, 2016 12:23:07 PM EDT alfonso wrote:
Hello everyone,
I'm trying to integrate the testing of the resulting yocto images using
Linaro's LAVA project.
For now I am only using qemux86 images.
Now, I am quite a newbie in both projects and maybe in general on the
subject of images so I might be asking the wrong questions.
So far, to test a qemu image using LAVA it is required a .img file. That
would be the simplest configuration. On the other hand, my yocto project
produces a .bin kernel file + .ext4 filesystem file. I don't seem to
find a proper configuration in LAVA for .bin + .ext4 file testing. I
presume there is a way to configure yocto to produce a .img file out of
these two guys but I don't seem to find how.
Would anyone have a recommendation?
We have been using LAVA to test our Yocto based product for about 1 1/2years
now using the produced .ext[34] and bzImage produced from a typical Yocto
build. We have been using LAVA 1 however and I am only now starting to move to
the latest LAVA 2. We have also been using hardware targets and not qemu but
that is overall inconsequential.
Since our move to LAVA 2 is in progress I can't currently give you a step by
step guide to accomplishing this. Let me look quickly today to see if the
existing definition of the qemu device type will allow for specifying a disk
image and kernel. If not then it either needs to be added or a new device type
created with allows it. On the bright side the LAVA folks have done a good job
about the layout of their code so jumping in to do this may seem to be a big
hurdle but once you jump in you will find most things where you would expect
them to be.
Alternatively you could use either a chroot or VM to update the .ext4 image
with a kernel and grub.
Anyways, sorry for sparse information. Again if you give me some time I can
provide you with more details. But definitely go ahead and dig in, you will
find that what you want to do is possible.
Mark Asselstine
Thanks in advance for your help :)
Best,
Alfonso
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: Add recipes and patches for 4.8 release
On Thu, Oct 13, 2016 at 1:55 AM, Andrei Gherzan wrote:
> On Thu, Oct 06, 2016 at 09:39:46PM -0700, Khem Raj wrote:
>> 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);
>> + u
Re: [yocto] Can I change the version of Yocto Project ?
On 2016年10月12日 22:05, 蔡尚義 wrote:
Hi Yocto Project:
Recently I downloaded the yocto project with the latest version
("krogoth") on my Ubuntu14.04 LTS.
But I found that Jethro version is the real version that I need to use
for BSP on APQ8053(Qualcomm chip)
So, How can I downgrade the version of yocto project to do this ?
Why not download Jethro directly?
Another question is that I found that the Desktop can not fit my
desktop monitor very well.
Maybe it was because your virtual-machine on windows.
So, how can I change the setting to let this issue disappeared ?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH V2 1/2] linux-raspberrypi: Add recipe for 4.8 release
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
[yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi_4.7.bb: Update to 4.7.7
Signed-off-by: Khem Raj
---
recipes-kernel/linux/linux-raspberrypi_4.7.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/recipes-kernel/linux/linux-raspberrypi_4.7.bb
b/recipes-kernel/linux/linux-raspberrypi_4.7.bb
index 44ac961..0315f8f 100644
--- a/recipes-kernel/linux/linux-raspberrypi_4.7.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_4.7.bb
@@ -1,8 +1,8 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-LINUX_VERSION ?= "4.7.0"
+LINUX_VERSION ?= "4.7.7"
-SRCREV = "d38b45a21294eaf01aa7568aaeb161d7553477e9"
+SRCREV = "a45a35c08598b23f9fd82e49c83b46c7d536244f"
SRC_URI =
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.7.y \
file://0001-fix-dtbo-rules.patch \
"
--
2.10.0
--
___
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] add dejavu-fonts to image
Hello,
In fact, the ttf-dejavu recipe doesn't provide a package with the same name. If
you look at the PACKAGES variable, you'll find that it provides ${PN}-sans,
${PN}-sans-mono, ${PN}-sans-condensed, ${PN}-serif , ${PN}-serif-condensed &
${PN}-mathtexgyre.
So you have to explicitly choose the packages you want.
Michel
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto recipe license
On 13 October 2016 at 09:49, Contrib Open Source < contrib.open.sou...@gmail.com> wrote: > 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 ? > The oe-core metadata is licensed under MIT, as explained in the LICENSE file. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Merging a custom SDK with meta-toolchain-qt5
hi all, I have built an image based on Toradex Colibri-T20 board. It's based on X11 with support of gtk3+. Works fine. To get our programs working on it, I have generated the dedicated SDK with bitbake populate_sdk with extra features in SDKIMAGE_FEATURES Then I have added a custom image to support Qt5 framework. I have generated the meta-toolchain-qt5. But in the SDK, I could not found the features addeded for my previus SDK (header and lib file of gtk3+ etc.) Is there a way to customize the meta-toolchain-qt5 so that it installs the features declared in the SDKIMAGE_FEATURES above ? Cheers, Kariom -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] add dejavu-fonts to image
Hello, thanks a lot the build work now !
But i have another issue, i would like to install the font in
/usr/lib/fonts, this is not the case for the moment (it 's for Qt5.7 use).
How i can said to yocto to install font (.ttf) on this folder please ?
regards
Mickaël
Le Thu, 13 Oct 2016 12:07:24 +0200, Michel D'HOOGE
a écrit:
Hello,
In fact, the ttf-dejavu recipe doesn't provide a package with the same
name. If you look at the PACKAGES variable, you'll find that it
>provides ${PN}-sans, ${PN}-sans-mono, ${PN}-sans-condensed, ${PN}-serif
, ${PN}-serif-condensed & ${PN}-mathtexgyre.
So you have to explicitly choose the packages you want.
Michel
--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] add dejavu-fonts to image
Hello, thanks a lot the build work now !
I'm very proud: this is the 1st time I can help someone on Yocto! This means a
lot to me ;-)
But i have another issue, i would like to install the font in /usr/lib/fonts,
this is not the case for the moment (it 's for Qt5.7 use). How i can said to
yocto to install font (.ttf) on this folder please ?
I also need to use Qt5.7, but since I'm currently on other tasks, you discover
the troubles a couple of hours before me. So let's try to debug this together…
1/ File ttf-dejavu_2.37.bb includes (requires) `ttf.inc` that is in the same
folder.
2/ File ttf.inc has the following method:
do_install() {
install -d ${D}${datadir}/fonts/truetype/
find ./ -name '*.tt[cf]' -exec install -m 0644 {}
${D}${datadir}/fonts/truetype/ \;
}
which is in turn appended by dejavu with:
do_install_append () {
install -d ${D}${sysconfdir}/fonts/conf.d/
install -m 0644 ${WORKDIR}/30-dejavu-aliases.conf
${D}${sysconfdir}/fonts/conf.d/
}
3/ The log of the install task of the recipe is
/tmp/work/all-poky-linux/ttf-dejavu/2.37-r7/temp/run.do_install
We have:
export datadir="/usr/share"
export sysconfdir="/etc"
I compared to my Debian system: the files are stored in the same folders. So it
seems this is qt that doesn't search in the "correct" place.
4/ After some grepping in meta-qt5, I have:
classes/qmake5_paths.bbclass
OE_QMAKE_PATH_LIBS = "${libdir}"
classes/qmake5_paths.bbclass
OE_QMAKE_PATH_QT_FONTS = "${OE_QMAKE_PATH_LIBS}/fonts"
5/ But I don't know what is the best solution now. We could change the
OE_QMAKE_PATH_QT_FONTS variable. But this implies to recompile many pieces, I
believe.
So I opt for changing the do_install function. The quick & dirty solution is to
create a ttf-dejavu_2.37.bbappend file that totally redefine the do_install
method.
do_install() {
install -d ${D}${datadir}/fonts/truetype/
find ./ -name '*.tt[cf]' -exec install -m 0644 {} ${D}${ libdir
}/fonts/truetype/ \;
install -d ${D}${sysconfdir}/fonts/conf.d/
install -m 0644 ${WORKDIR}/30-dejavu-aliases.conf
${D}${sysconfdir}/fonts/conf.d/
}
I can't test it right now, but I hope this helps you.
Michel
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Merging a custom SDK with meta-toolchain-qt5
Hi, > Is there a way to customize the meta-toolchain-qt5 so that it > installs the features declared in the SDKIMAGE_FEATURES above ? How did you generate the Qt5 toolchain? Because according to the reference manual: The SDKIMAGE_FEATURES is e quivalent to IMAGE_FEATURES. However, this variable applies to the SDK generated from an image using the following command: $ bitbake -c populate_sdk imagename There is a populate_sdk_qt5 class in meta-qt5. But I don't know how to merge this with the previous command :-/ Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for yocto-2.2.rc1.rc1 now available.
A release candidate build for yocto-2.2.rc1 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.2.rc1 Please begin QA on this build as soon as possible. Build hash information: meta-qt4 : fc9b050569e94b5176bed28b69ef28514e4e4553 meta-intel : 9052773016727a9398d1e6b6830dc94f3203f754 meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f poky : 371ab635086e2878ada1f00a59c7ec826481ba0a \nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: git://git.yoctoproject.org/yocto-autobuilder\nEmail: pi...@toganlabs.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Release Candidate Build for yocto-2.2.rc1.rc1 now available.
A release candidate build for yocto-2.2.rc1 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.2.rc1 Please begin QA on this build as soon as possible. Build hash information: meta-qt4 : fc9b050569e94b5176bed28b69ef28514e4e4553 meta-intel : 9052773016727a9398d1e6b6830dc94f3203f754 meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f poky : 371ab635086e2878ada1f00a59c7ec826481ba0a \nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: git://git.yoctoproject.org/yocto-autobuilder\nEmail: pi...@toganlabs.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] add dejavu-fonts to image
Thanks for this. I will try and let you know the solution worked for me !
regards
Le Thu, 13 Oct 2016 16:56:34 +0200, Michel D'HOOGE
a écrit:
Hello, thanks a lot the build work now !
I'm very proud: this is the 1st time I can help someone on Yocto! This
means a lot to me ;-)
But i have another issue, i would like to install the font in
/usr/lib/fonts, this is not the case for the moment (it 's >>for Qt5.7
use). How i can said to yocto to install font (.ttf) on this folder
please ?
I also need to use Qt5.7, but since I'm currently on other tasks, you
discover the troubles a couple of hours before >me. So let's try to
debug this together…
1/ File ttf-dejavu_2.37.bb includes (requires) `ttf.inc` that is in the
same folder.
2/ File ttf.inc has the following method:
do_install() {
install -d ${D}${datadir}/fonts/truetype/
find ./ -name '*.tt[cf]' -exec install -m 0644 {}
${D}${datadir}/fonts/>truetype/ \;
}
which is in turn appended by dejavu with:
do_install_append () {
install -d ${D}${sysconfdir}/fonts/conf.d/
install -m 0644 ${WORKDIR}/30-dejavu-aliases.conf
${D}${sysconfdir}/fonts/>conf.d/
}
3/ The log of the install task of the recipe is
/tmp/work/all-poky-linux/ttf-dejavu/2.37-r7/temp/run.do_install
We have:
export datadir="/usr/share"
export sysconfdir="/etc"
I compared to my Debian system: the files are stored in the same
folders. So it seems this is qt that doesn't search >in the "correct"
place.
4/ After some grepping in meta-qt5, I have:
classes/qmake5_paths.bbclass
OE_QMAKE_PATH_LIBS = "${libdir}"
classes/qmake5_paths.bbclass
OE_QMAKE_PATH_QT_FONTS = "${OE_QMAKE_PATH_LIBS}/fonts"
5/ But I don't know what is the best solution now. We could change the
OE_QMAKE_PATH_QT_FONTS variable. >But this implies to recompile many
pieces, I believe.
So I opt for changing the do_install function. The quick & dirty
solution is to create a ttf-dejavu_2.37.bbappend file >that totally
redefine the do_install method.
do_install() {
install -d ${D}${datadir}/fonts/truetype/
find ./ -name '*.tt[cf]' -exec install -m 0644 {}
${D}${libdir}/fonts/>truetype/ \;
install -d ${D}${sysconfdir}/fonts/conf.d/
install -m 0644 ${WORKDIR}/30-dejavu-aliases.conf
${D}${sysconfdir}/fonts/>conf.d/
}
I can't test it right now, but I hope this helps you.
Michel
--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Release Candidate Build for yocto-2.2.rc1.rc1 now available.
On Thu, 2016-10-13 at 15:36 +, Poky Build User wrote: > A release candidate build for yocto-2.2.rc1 is now available at: > > > http://autobuilder.yoctoproject.org/pub/releases/yocto-2.2.rc1 > > > Please begin QA on this build as soon as possible. Please don't, this build isn't ready for QA. The debian8 builder recently failed to send a QA mail (no sendmail in PATH) and this mail is testing it now works. Thanks, Joshua > Build hash information: > meta-qt4 : fc9b050569e94b5176bed28b69ef28514e4e4553 > meta-intel : 9052773016727a9398d1e6b6830dc94f3203f754 > meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae > meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f > poky : 371ab635086e2878ada1f00a59c7ec826481ba0a > > \nThis is an automated message from\nThe Yocto Project > Autobuilder\nGit: git://git.yoctoproject.org/yocto- > autobuilder\nEmail: pi...@toganlabs.com - 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] add dejavu-fonts to image
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
[yocto] Big endian ARM machine with NEON wanted
Hi, Does anybody know a big endian and common machine supporting NEON? I would need one for testing my port of portaudio. Thanks in advance Andreas -- ___ 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
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? Thanks, Joshua - 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] [yocto-autobuilder][PATCH] PublishArtifacts.py: deal only with built toolchains, cp also md5 and manifests
On Wed, 2016-10-12 at 17:29 +0200, Beth 'pidge' Flanagan wrote: > On Mon, 2016-10-10 at 01:44 -0500, gm...@reliableembeddedsystems.com > wrote: > > > > > > > A few notes (not picking on this patch but it does point out some > design failures and I want to at least get this on folks radar). > > I've been unhappy with how DeployArtifacts work for sometime. > > Long ago, when I wrote DeployArtifacts, it was "get it working, we'll > refactor later" and that refactor never happened. So I'm up for > ideas. > > I would like a deploy infrastructure that: > > a. Is distro/image name/etc agnostic (aka, poky and image names and > paths hardcoded. ick.). > b. Is perhaps config file driven. > c. Had much less of the cruft that exists withing DeployArtifacts. > > So. Thoughts on this? I'd be willing to hear suggestions on how to do > this before I go and spend some time ripping this apart post release? It's quite useful to have a list of expected output of the build so that this step can fail if a component which should be published is missing. I'd been planning to take a look at rewriting this build step after the release and my initial thoughts were towards something config file driven. Thanks, Joshua -- ___ 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
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! 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. I do not want PublishArtifacts toolchain(s) to find out that something went wrong in previous build steps, but I would want it to copy over whatever was built (and not to fail if something I did not build is missing). As a quick and dirty alternative I would also be happy with a solution based on additional PublishArtifacts steps like: toolchain_i686 for 32 bit only (only the 32 bit toolchain) toolchain_x86_64 for 64 bit only (only the 64 bit toolchain) if that helps. Then in my config file I just use toolchain_x86_64 instead of toolchain in my PublishArtifacts step to indicate that I just want the 64 bit version. To publish both you could use toolchain_i686 and toolchain_x86_64 in the PublishArtifacts step. I find it a bit confusing to write toolchain and to expect various 64 bit and 32 bit toolchains to be published. BTW what happens here[1] if one toolchain does not build? I think even without my patch you'll not be able to detect the problem, since BuildToolchainImages is being called 4 times so two 32 bit and two 64 bit toolchains should be built. You'll just get an error in PublishArtifacts before my patch if no 32 bit or no 64 bit toolchain is being built. Nobody counts how many should be there. So I would say the best would be to count how many toolchains should be built (count BuildToolchainImages in combination with SDKMACHINE) and check if that's the case in PublishArtifacts. No idea if and how this can be done. Thanks, Joshua Regards, Robert [1] http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/tree/buildset-config.controller/nightly-arm.conf - 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
[yocto] Migration info - runqemu
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 -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration info - runqemu
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. 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=no -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] Yocto recipe license
Hello, thanks for pointing me to oe-core LICENSE file. Just to be sure, from: https://github.com/openembedded/openembedded-core/blob/master/LICENSE "All metadata is MIT licensed unless otherwise stated. Source code included in tree for individual recipes is under the LICENSE stated in the associated recipe (.bb file) unless otherwise stated. License information for any other files is either explicitly stated or defaults to GPL version 2." Here "metadata" stands for "oe-core recipe", right ? What if we extend (*.bbappend) a GPLv2 recipe: is it "contaminated" or not ? Regards, contrib 2016-10-13 12:37 GMT+02:00 Burton, Ross : > > On 13 October 2016 at 09:49, Contrib Open Source < > contrib.open.sou...@gmail.com> wrote: > >> 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 ? >> > > The oe-core metadata is licensed under MIT, as explained in the LICENSE > file. > > Ross > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Big endian ARM machine with NEON wanted
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? Kind regards, Mike Looijmans System Expert TOPIC Products Materiaalweg 4, NL-5681 RJ Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Big endian ARM machine with NEON wanted
On Fri, Oct 14, 2016 at 7:41 AM, 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? Does QEMU support NEON? Andreas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Merging a custom SDK with meta-toolchain-qt5
Hi Karim, I understand your problem but unfortunately I still have a limited understanding of the intrication of the whole metadata system… The good news is that the meta-toolchain-qt5 recipe is quite empty. So I think your best option is to patch the populate_sdk task to include what is added by the qt5 layer. Once you have something working, you can then think on how to make it more permanent. grep & find will be your best friends --- at least, they are for me ;-) M. - Mail original - > De: "Karim ATIKI" > À: "Michel D'HOOGE" > Envoyé: Jeudi 13 Octobre 2016 17:46:59 > Objet: RE: [yocto] Merging a custom SDK with meta-toolchain-qt5 > Hi Michel, > Indeed, with my first image, I've generated the sdk as follow: > $ bitbake -c populate_sdk my-image-name > In the "my-image-name.bb" I've added features : > IMAGE_INSTALL_append = " foo gtk+3 libstdc++ " > SDKIMAGE_FEATURES_append = " libstdc++-dev " > So the resulting sdk contained all the necessary headers I needed, > including libgtk+.so and its respective header files. > I've created a new image, my-qtimage.bb" based on "my-image-name.bb". > I've included all Qt5 stuff with IMAGE_INSTALL_append = " qtbase qt3d > ... " > The image is generated fine. Good. > Then, to generate the SDK instead of doing that: > $ bitbake -c populate_sdk my-qtimage > I've prefered using the dedicated recipe of meta-qt5: > $ bitbake meta-toolchainqt5 > But of course it did not include my features above. > I just wonder what would be the best solution to achieve it correctly > ? > Writing a meta-toolchainqt5.bbapend ? > Karim > De : Michel D'HOOGE > Envoyé : jeudi 13 octobre 2016 17:11 > À : yocto > Cc : Karim ATIKI > Objet : Re: [yocto] Merging a custom SDK with meta-toolchain-qt5 > Hi, > > Is there a way to customize the meta-toolchain-qt5 so that it > > installs the features declared in the SDKIMAGE_FEATURES above ? > How did you generate the Qt5 toolchain? Because according to the > reference manual: > The SDKIMAGE_FEATURES is e quivalent to IMAGE_FEATURES. However, this > variable applies to the SDK generated from an image using the > following command: > $ bitbake -c populate_sdk imagename > There is a populate_sdk_qt5 class in meta-qt5. But I don't know how > to merge this with the previous command :-/ > Michel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
