[yocto] Regarding Error occuring after changing configuration
Hi Team, I am getting error while building yocto after changing the configuration. Please find set of below commands that i have used $ bitbake virtual/kernel -c menuconfig $ bitbake virtual/kernel $ bitbake -k agl-demo-platform *| Disk ~/build/tmp/work/nitrogen6x-agl-linux-gnueabi/agl-demo-platform/1.0-r0/deploy-agl-demo-platform-image-complete/agl-demo-platform-nitrogen6x-20180705063932.rootfs.sdcard: 2185MB* *| Sector size (logical/physical): 512B/512B* *| Partition Table: msdos* *| Disk Flags:* *| * *| Number Start End SizeType File system Flags* *| 1 4194kB 12.6MB 8389kB primary lba* *| 2 12.6MB 2181MB 2168MB primary* *| * *| mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows* *| mkfs.fat 4.1 (2017-01-24)* *| Disk full* *| WARNING: exit code 1 from a shell command.* *| ERROR: Function failed: do_image_sdcard (log file is located at ~/build/tmp/work/nitrogen6x-agl-linux-gnueabi/agl-demo-platform/1.0-r0/temp/log.do_image_sdcard.6362)* *ERROR: Task (~/kapil/meta-agl-demo/recipes-platform/images/agl-demo-platform.bb:do_image_sdcard) failed with exit code '1'* *NOTE: Tasks Summary: Attempted 7063 tasks of which 7059 didn't need to be rerun and 1 failed.*I think due to change in configuration rootfs size is increased and the current rootfs size is small that is not able to accommodate the thae changed size. If it is so can anybody please provide steps to change the rootfs size . Can you please give your inputs regarding this. *Regards,* *Abhishek Rai* -- The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you for your cooperation. -- _This e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. If you are not an intended recipient, please delete this message. Thank you. _ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Creating a recipe for python3-pillow
Hey, I'm fiddeling around with yocto. I want to move some python stuff onto an embedded board and use the nxp mx8 yocto. Everything worked as expected until now, I was able to create yocto recipes for python modules like pyv4l2 (is there any interest for recipes like these to be commited to meta-python?). Now I wanted to install pillow for some image manipulation, but whereas other python module recipes worked fine, this one fails and I don't understand why. Yocto reports missing setuptools: Log data follows: | DEBUG: Executing shell function do_configure | NOTE: make clean | python setup.py clean | Traceback (most recent call last): | File "setup.py", line 22, in | from setuptools import Extension, setup | ImportError: No module named setuptools I've googled around and everything suggests that inherit setuptools3 is missing, but it's present in my recipe. This is my python3-pillow_5.2.0.bb: SUMMARY = "Pillow (The friendly PIL fork)" HOMEPAGE = "http://python-pillow.org/"; LICENSE = "EPLv1" LIC_FILES_CHKSUM = "file://LICENSE;md5=c6379001ecb47e2a0420c40177fc1125" SRC_URI[md5sum] = "52d93a34f4180abcff04876f23eaa9b9" PYPI_PACKAGE = "Pillow" inherit pypi setuptools3 BBCLASSEXTEND = "native nativesdk" Any idea whats missing or what I am doing wrong (other than that the license line is incorrect)? Best regards, Olli -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] [yocto-ab-helper] clobberdir: Fix Unicode data expansion with utils API
On Thu, 2018-07-05 at 13:34 +0800, Aaron Chan wrote:
> This fix is to move clobberdir from python2 to python3 to resolve
> unicode data
> in python2 and change the data extraction expansion from
> ourconfig["TRASH_DIR"]
> to utils.getconfig("TRASH_DIR", ourconfig) on "Clobber build dir"
> BuildStep
>
> Signed-off-by: Aaron Chan
> ---
> janitor/clobberdir | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/janitor/clobberdir b/janitor/clobberdir
> index 5e04ed7..b05a876 100755
> --- a/janitor/clobberdir
> +++ b/janitor/clobberdir
> @@ -1,4 +1,4 @@
> -#!/usr/bin/env python2
> +#!/usr/bin/env python3
> #
> # Delete a directory using the ionice backgrounded command
> #
At this point I think we're all getting frustrated with this. Please
can you give patches a sanity check when you're sending them. You
mention in the commit message what you need to do but the getconfig()
change is missing from the patch itself. This has happened with several
previous patches too where there were pieces missing. I deal with a lot
of patches and I can't fix up each one.
The commit message mentions its fixing something but not what (a
regression introduced by a previous change).
In the interests of resolving this I've fixed up this commit and merged
it:
http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/commit/?id=54f848380fc77a9b9523bd85cd1cdce075bfb96e
Cheers,
Richard
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] [yocto-ab-helper] clobberdir: Fix Unicode data expansion with utils API
My apologizes to that as my local copy contains the fixes from the previous
commits. Therefore this commit builts on top of it and only contains the delta
on the current changes, this is the reason why its not complete.
Thanks again for the merge.
-Original Message-
From: richard.pur...@linuxfoundation.org
[mailto:richard.pur...@linuxfoundation.org]
Sent: Thursday, July 5, 2018 5:54 PM
To: Chan, Aaron Chun Yew ; yocto@yoctoproject.org
Subject: Re: [PATCH] [yocto-ab-helper] clobberdir: Fix Unicode data expansion
with utils API
On Thu, 2018-07-05 at 13:34 +0800, Aaron Chan wrote:
> This fix is to move clobberdir from python2 to python3 to resolve
> unicode data in python2 and change the data extraction expansion from
> ourconfig["TRASH_DIR"] to utils.getconfig("TRASH_DIR", ourconfig) on
> "Clobber build dir"
> BuildStep
>
> Signed-off-by: Aaron Chan
> ---
> janitor/clobberdir | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/janitor/clobberdir b/janitor/clobberdir index
> 5e04ed7..b05a876 100755
> --- a/janitor/clobberdir
> +++ b/janitor/clobberdir
> @@ -1,4 +1,4 @@
> -#!/usr/bin/env python2
> +#!/usr/bin/env python3
> #
> # Delete a directory using the ionice backgrounded command #
At this point I think we're all getting frustrated with this. Please can you
give patches a sanity check when you're sending them. You mention in the commit
message what you need to do but the getconfig() change is missing from the
patch itself. This has happened with several previous patches too where there
were pieces missing. I deal with a lot of patches and I can't fix up each one.
The commit message mentions its fixing something but not what (a regression
introduced by a previous change).
In the interests of resolving this I've fixed up this commit and merged
it:
http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/commit/?id=54f848380fc77a9b9523bd85cd1cdce075bfb96e
Cheers,
Richard
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Creating a recipe for python3-pillow
On 5 July 2018 at 08:26, Oliver Westermann wrote: > I'm fiddeling around with yocto. I want to move some python stuff onto an > embedded board and use the nxp mx8 yocto. Everything worked as expected > until now, I was able to create yocto recipes for python modules like pyv4l2 > (is there any interest for recipes like these to be commited to > meta-python?). > > Now I wanted to install pillow for some image manipulation, but whereas > other python module recipes worked fine, this one fails and I don't > understand why. > > Yocto reports missing setuptools: > > Log data follows: > | DEBUG: Executing shell function do_configure > | NOTE: make clean > | python setup.py clean > | Traceback (most recent call last): > | File "setup.py", line 22, in > | from setuptools import Extension, setup > | ImportError: No module named setuptools > > I've googled around and everything suggests that inherit setuptools3 is > missing, but it's present in my recipe. This is my python3-pillow_5.2.0.bb: > > SUMMARY = "Pillow (The friendly PIL fork)" > HOMEPAGE = "http://python-pillow.org/"; > LICENSE = "EPLv1" > LIC_FILES_CHKSUM = "file://LICENSE;md5=c6379001ecb47e2a0420c40177fc1125" > > SRC_URI[md5sum] = "52d93a34f4180abcff04876f23eaa9b9" > > PYPI_PACKAGE = "Pillow" > > inherit pypi setuptools3 > > BBCLASSEXTEND = "native nativesdk" > > Any idea whats missing or what I am doing wrong (other than that the license > line is incorrect)? Oh, that's a fun one. So setuptools/distutils/etc doesn't have the concept of a "configure" phase but it also doesn't remove the default implementation. The default implementation will try to do a 'make clean' first to remove existing build artifacts. Normally this does nothing with Python code as there's never a Makefile, but pillow has a Makefile. This makefile does 'python setup.py clean', which is running the *host* Python2 and you don't have distutils installed. So, it fails. Three solutions in order of hackiness (more to less) 1) Set CLEANBROKEN="1" in the recipe to stop the clean happening 2) Nullify do_configure in the recipe with do_configure[noexec] = "1" 3) Override do_configure in distutils3.bbclass to call setup.py directly to do a clean in do_configure I'd say do (1) in your recipe and I'll send a patch for (3) to oe-core. And yes, this recipe would be very welcome in meta-python. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] porting gRPC into Yocto
Hi, After reading several documents, there seems to be several methods to add/remove packages from a build. I just want to make sure I am using the correct method that falls into YOCTO architecture. In local.conf file, I can use: IMAGE_INSTALL_remove = " dropbear" IMAGE_INSTALL_append = " openssh net-snmp " To remove dropbear and add openssh and net-snmp into image. Is this the right way of doing it? Do I use 'DISTRO_FEATURES_remove' or simply ' IMAGE_INSTALL_remove' ? Does Yocto fetch *.bb files and source files just by adding these commands in local.conf or I need more steps to do? Thanks, S. On Thu, Jun 21, 2018 at 3:05 PM, Stephen Lawrence < stephen.lawre...@renesas.com> wrote: > >From: yocto-boun...@yoctoproject.org [mailto:yocto-bounces@ > yoctoproject.org] On Behalf Of Simon Chamlian > >Sent: 21 June 2018 19:50 > >To: Rudolf J Streif > >Cc: yocto@yoctoproject.org > >Subject: Re: [yocto] porting gRPC into Yocto > > > >Thank you everyone for such a prompt response. > > > >What do I do with the http://cgit.openembedded.org/ > meta-openembedded/tree/meta-networking/recipes-devtools/ > grpc/grpc_1.8.5.bb?h=master recipe file (sorry >for my ignorance, it has > been 1 day I am using Yocto)? > > > >Simon > > Hi Simon, > > The Yocto Project online documentation set [1] contains some useful > development manuals that guide you through some > common use cases for using Yocto. Such as adding a package to an existing > image. > > There have also been some good books written on embedded development with > Yocto. A more recent one is > "Embedded Linux Systems with the Yocto Project" by Rudolf J. Streif from > Prentice Hall. You'll easily get a return on the > investment. > > [1] https://www.yoctoproject.org/docs/ > > Regards > > Steve > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] porting gRPC into Yocto
On 5 July 2018 at 15:49, Simon Chamlian wrote: > After reading several documents, there seems to be several methods to > add/remove packages from a build. > I just want to make sure I am using the correct method that falls into YOCTO > architecture. > > In local.conf file, I can use: > > IMAGE_INSTALL_remove = " dropbear" > IMAGE_INSTALL_append = " openssh net-snmp " > > To remove dropbear and add openssh and net-snmp into image. > > Is this the right way of doing it? Do I use 'DISTRO_FEATURES_remove' or > simply ' IMAGE_INSTALL_remove' ? IMAGE_INSTALL specifies what packages go into the image. DISTRO_FEATURES is unrelated and are course-grained features that control how software is built. Note that to change SSH server there is an IMAGE_FEATURE you can fiddle instead: remove ssh-server-dropbear and add ssh-server-openssh. > Does Yocto fetch *.bb files and source files just by adding these commands > in local.conf or I need more steps to do? Those commands will impact all images so when you build an image it will make the changes. Note that for the "all images" reason it is recommended that you write your own image recipe instead of using core-image-minimal or similar and lots of local.conf tweaks. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] IMX6Q add new sound simple sound card
Hello all, I'm new to Linux/Yocto world. I'm working on iMX6Q and I need to add a new sound card and recognized from alsamixer. I spent days on internet looking for examples and tutorials but at the moment alsa never see my sound card. This is one of the tutorials I followed https://elixir.bootlin.com/linux/v4.5/source/Documentation/devicetree/bindings/sound/simple-card.txt What I've done? - Activated support for generic sound board on menuconfig - Added new "sound" node in device tree file with minimal properties/subnotes - Compiled the kernel - Compiled and flashed the image but alsamixer still doesn't recognize my sound card, what am I missing? Thanks. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problem on building sdk on Docker container
Actually I was facing the following issue while building my Yocto SDK on Docker container [04:25] Removing intermediate container 4f3743321874 ---> 674e007553da Step 4/5 : RUN chmod +x /tmp/$META_TOOLCHAIN ---> Running in ababb0649ea1 Removing intermediate container ababb0649ea1 ---> 5f558946851e Step 5/5 : RUN /tmp/$META_TOOLCHAIN ---> Running in 929c7ea6af59 Poky (Yocto Project Reference Distro) SDK installer version 2.4.3 = You are about to install the SDK to "/home/akash/rpil/rpi-build/tmp" Extracting SDK.done Setting it up...ls: cannot access '/home/akash/rpil/rpi-build/tmp/environment-setup-cortexa7hf-neon-vfpv4-poky-linux-gnueabi': No such file or directory SDK relocate failed, could not get executalbe files The command '/bin/sh -c /tmp/$META_TOOLCHAIN' returned a non-zero code: 1 I was facing this issue even if when environment-setup-cortexa7hf-neon-vfpv4-poky-linux-gnueabi is present in my tmp directory. My sysroots directory is empty .I am assuming that ,that may be the reason for SDK.I have tried including the target directory in my toolchain( poky-glibc-x86_64-meta-toolchain-cortexa7hf-neon-vfpv4-toolchain-2.4.3.sh) to /home/akash/rpil/rpi-build/tmp but it is still not working out. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] struggling with initramfs
On Wed, Jul 4, 2018 at 11:23 PM, Zoran Stojsavljevic
wrote:
> Hello to all,
>
> I have my own YOCTO recipe how I do the initramfs.
>
> Usually, some of these are missing in kernel .config file:
>
> CONFIG_BLK_DEV_INITRD=y
> CONFIG_RD_GZIP=y
> CONFIG_RD_BZIP2=y
> CONFIG_RD_LZMA=y
> CONFIG_RD_XZ=y
> CONFIG_RD_LZO=y
> CONFIG_RD_LZ4=y
>
> Please, check (they should be on) the CONFIG_DECOMPRESS_* options and if
> not, please, turn them on.
>
> To do this, please, for YOCTO use the following (to reconfigure kernel
> .config):
> bitbake -c menuconfig virtual/kernel
>
> Also, in the local.conf I have the following set:
>
> DISTRO_FEATURES_append = " ram"
There is no standard distro feature called "ram". Perhaps this is
something specific to your BSP layer?
> IMAGE_FSTYPES_append = " cpio.xz"
>
> Then I do: bitbake -k core-image-minimal, and from:
> .../build/tmp/tmp/deploy/images/
>
> Take my .cpio.xz as initramfs. Also, I take accordingly
> zImage and .dtb files as well.
>
> I prepend to initramfs.cpio.xz u-boot header:
> mkimage -n 'Ramdisk Image' -A arm -O linux -T ramdisk -C gzip -d
> initramfs.cpio.xz initramfs.cpio.xz.uboot
>
> And then write tiny U-Boot ash script to tftp (from host) all three files to
> the target platform.
This advice and these instructions are all fine. However, just for the
record, creating a standalone cpio archive and arranging for the
bootloader to load the kernel and cpio archive into DRAM as separate
images before booting the kernel is not solving the same problem as
embedding a cpio archive inside the kernel image via OE's
INITRAMFS_IMAGE_BUNDLE option.
> On Wed, Jul 4, 2018 at 8:57 PM, Ferry Toth wrote:
>>
>> Tim Hammer wrote:
>>
>> > Can anyone point me to a step-by-step tutorial or simple how-to on
>> > creating and using an initramfs with my kernel for ARM aarch64?
>> >
>> >
>> > I have tried creating my own:
>> > - boot-image.bb file with IMAGE_FSTYPES = "cpio.gz".
>> > - local.conf has INITRAMFS_IMAGE_BUNDLE = "1"
>> > - linux.bbappend has INITRAMFS_IMAGE = "boot-image"
>> >
>> > This all seems to be "correct" to the extent that bitbake linux tries to
>> > do the right thing.
>> >
>> > However, I get a failure in do_bundle_initramfs- "mv: cannot stat
>> > 'arch/arm64/boot/Image': No such file or directory".
>> >
>> > To the best of my (limited) debugging abilities with Yocto, it seems
>> > like
>> > the kernel image backup has already been run when it gets to this point
>> > and the Image file in that directory has already been moved to
>> > Image.bak.
>> > If I comment out the mv statement in kernel.bbclass causing the failure,
>> > the process continues, but the initramfs does not seem to get populated
>> > or
>> > perhaps installed into my kernel image as I get kernel panics that I
>> > have
>> > been unable to get past.
>> >
>> >
>> > I decided to take a different approach and try using the
>> > core-image-minimal-initramfs recipe as INITRAMFS_IMAGE. By commenting
>> > out
>> > the COMPATIBLE_HOST entry I am able to build a kernel for ARM aarch64. I
>> > can even seem to boot into this initramfs- it counts down waiting for
>> > removable media; seems to find my primary rootfs on sda3, but there is
>> > no
>> > rootfs.img file there so says it is dropping to a shell (although I
>> > never
>> > get a prompt...).
>>
>> We have taken this approach here
>>
>> https://github.com/edison-fw/meta-intel-edison/tree/master/meta-intel-edison-distro/recipes-core
>>
>> There are 2 images, the rootfs and the initramfs. And we overload the
>> init-live.sh
>> to load certain kernel modules and acpi-tables then switchroot to the
>> rootfs.
>>
>> > Thinking I could start with that recipe and work to get rid of the live
>> > stuff and just get to a busybox prompt before trying to run my unique
>> > init
>> > commands, I copied core-image-minimal-initramfs.bb to my-
>> > core-image-minimal-initramfs.bb in my layer and changed INITRAMFS_IMAGE
>> > to
>> > "my- core-image-minimal-initramfs".
>> > However, I obviously missed something in the configuration as I get an
>> > error in go_bundle_initramfs again:
>> > kernel-source/scripts/gen_initramfs_list.sh:
>> > Cannot open
>> >
>> > '/.../linux-qoriq/4.14-r0/build/usr/my-core-image-minimal-initramfs-{machine}.cpio'
>> >
>> > Any help would be greatly appreciated.
>> > Thank you!
>>
>>
>> --
>> ___
>> 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] Regarding Error occuring after changing configuration
you can use IMAGE_ROOTFS_SIZE ?= *"8192"* to increase Rootfs size. On Thu, Jul 5, 2018 at 12:16 AM Abhishek Kumar Rai < abhish...@eximiusdesign.com> wrote: > Hi Team, > > I am getting error while building yocto after changing the configuration. > > Please find set of below commands that i have used > $ bitbake virtual/kernel -c menuconfig > $ bitbake virtual/kernel > $ bitbake -k agl-demo-platform > > *| Disk > ~/build/tmp/work/nitrogen6x-agl-linux-gnueabi/agl-demo-platform/1.0-r0/deploy-agl-demo-platform-image-complete/agl-demo-platform-nitrogen6x-20180705063932.rootfs.sdcard: > 2185MB* > *| Sector size (logical/physical): 512B/512B* > *| Partition Table: msdos* > *| Disk Flags:* > *| * > *| Number Start End SizeType File system Flags* > *| 1 4194kB 12.6MB 8389kB primary lba* > *| 2 12.6MB 2181MB 2168MB primary* > *| * > *| mkfs.fat: warning - lowercase labels might not work properly with DOS > or Windows* > *| mkfs.fat 4.1 (2017-01-24)* > *| Disk full* > *| WARNING: exit code 1 from a shell command.* > *| ERROR: Function failed: do_image_sdcard (log file is located at > ~/build/tmp/work/nitrogen6x-agl-linux-gnueabi/agl-demo-platform/1.0-r0/temp/log.do_image_sdcard.6362)* > *ERROR: Task > (~/kapil/meta-agl-demo/recipes-platform/images/agl-demo-platform.bb:do_image_sdcard) > failed with exit code '1'* > > > *NOTE: Tasks Summary: Attempted 7063 tasks of which 7059 didn't need to be > rerun and 1 failed.*I think due to change in configuration rootfs size is > increased and the current rootfs size is small that is not able to > accommodate the thae changed size. > If it is so can anybody please provide steps to change the rootfs size . > > Can you please give your inputs regarding this. > > > *Regards,* > > *Abhishek Rai* > > The information contained in this e-mail message (including any > > attachments) may be confidential, proprietary, privileged, or otherwise > > exempt from disclosure under applicable laws. It is intended to be > > conveyed only to the designated recipient(s). Any use, dissemination, > > distribution, printing, retaining or copying of this e-mail (including its > > attachments) by unintended recipient(s) is strictly prohibited and may > > be unlawful. If you are not an intended recipient of this e-mail, or > believe > > that you have received this e-mail in error, please notify the sender > > immediately (by replying to this e-mail), delete any and all copies of > > this e-mail (including any attachments) from your system, and do not > > disclose the content of this e-mail to any other person. Thank you for > your cooperation. > > *This e-mail message (including any attachments) may be confidential, > proprietary, privileged, or otherwise exempt from disclosure under > applicable laws. If you are not an intended recipient, please delete this > message. Thank you.* > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- Thanks and Regards, Prakash K S +91 9620140303 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [layerindex-web][PATCH 5/7] update: ignore recommends when ordering layers
Hi Robert On Wednesday, 4 July 2018 7:52:05 PM NZST you wrote: > I'm sorry to say that I met layerindex' loaddata problems yesterday and > today, > I still didn't find the root cause. Have you tried dumpdata and loaddata > recently, please ? > > What I did was: > > $ python3 manage.py dumpdata --settings settings --exclude=contenttypes > --exclude=auth.Permission --exclude=corsheaders >dumped.json > > On another environment: > Setup database to sqlite3 in settings.py. > $ python3 manage.py loaddata --settings settings dumped.json > > The first problem I got was: > [snip] >File > "/buildarea1/lyang1/layerindex-web/.venv/lib/python3.5/site-packages/reversion/revisions.py", > > line 410, in _assert_registered > model=model, > reversion.errors.RegistrationError: Problem installing fixture > '/buildarea1/lyang1/layerindex-web/dumped.json': 'layerindex.models.Distro'> has not been registered with django-reversion > [snip] > > I think it is because we didn't use @reversion.register() for the class, so I > added them to layerindex/models.py, then I got other errors: > > [snip] >File > "/buildarea1/lyang1/layerindex-web/.venv/lib/python3.5/site-packages/reversion/models.py", > > line 272, in _local_field_dict > field_dict[field.attname] = getattr(obj, field.attname) > AttributeError: Problem installing fixture > '/buildarea1/lyang1/layerindex-web/dumped.json': 'Branch' object has no > attribute 'layerbranch_id' Hmm, that's odd. Branch shouldn't have layerbranch_id, it's the other way around - LayerBranch has a branch_id. > I'm not sure what's wrong atm, need more investigations. > > I need loaddata on my localhost to do development testing, so I can't start > work on update.py until I fix the loaddata problem. I have used loaddata and dumpdata here (a couple of times) but not recently. I did not experience these issues before though. However these don't seem like issues that would have started as a result of this patchset (or indeed recent changes, other than perhaps an upgrade of django-reversion), have you been using loaddata/dumpdata prior to this? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [layerindex-web][PATCH 5/7] update: ignore recommends when ordering layers
On 07/06/2018 01:28 PM, Paul Eggleton wrote: Hi Robert On Wednesday, 4 July 2018 7:52:05 PM NZST you wrote: I'm sorry to say that I met layerindex' loaddata problems yesterday and today, I still didn't find the root cause. Have you tried dumpdata and loaddata recently, please ? What I did was: $ python3 manage.py dumpdata --settings settings --exclude=contenttypes --exclude=auth.Permission --exclude=corsheaders >dumped.json On another environment: Setup database to sqlite3 in settings.py. $ python3 manage.py loaddata --settings settings dumped.json The first problem I got was: [snip] File "/buildarea1/lyang1/layerindex-web/.venv/lib/python3.5/site-packages/reversion/revisions.py", line 410, in _assert_registered model=model, reversion.errors.RegistrationError: Problem installing fixture '/buildarea1/lyang1/layerindex-web/dumped.json': has not been registered with django-reversion [snip] I think it is because we didn't use @reversion.register() for the class, so I added them to layerindex/models.py, then I got other errors: [snip] File "/buildarea1/lyang1/layerindex-web/.venv/lib/python3.5/site-packages/reversion/models.py", line 272, in _local_field_dict field_dict[field.attname] = getattr(obj, field.attname) AttributeError: Problem installing fixture '/buildarea1/lyang1/layerindex-web/dumped.json': 'Branch' object has no attribute 'layerbranch_id' Hmm, that's odd. Branch shouldn't have layerbranch_id, it's the other way around - LayerBranch has a branch_id. I'm not sure what's wrong atm, need more investigations. I need loaddata on my localhost to do development testing, so I can't start work on update.py until I fix the loaddata problem. I have used loaddata and dumpdata here (a couple of times) but not recently. I did not experience these issues before though. However these don't seem like issues that would have started as a result of this patchset (or indeed recent changes, other than perhaps an upgrade of django-reversion), have you been using loaddata/dumpdata prior to this? dumpdata/loaddata worked well before March, Konrad (in CC) worked it around by: dumpdata --exclude=corsheaders --exclude=reversion.version --exclude=reversion.revision --exclude=captcha.captchastore --exclude=sessions.session So I can loaddata now. I've finished patch for 5/7, but I met other problems when testing on completely new branch which caused by recently changes, I will fix them and send out patches later // Robert Cheers, Paul -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] struggling with initramfs
> There is no standard distro feature called "ram". Perhaps this is > something specific to your BSP layer? Yeah, I noticed that. There is " nfs" parameter, but looks somehow peculiar: not in line with initramfs creation. I know that the whole line: DISTRO_FEATURES_append = " ram" looks bogus/useless, but YOCTO build system does not complain either. Maybe, you YOCTO guys, you do want to do some action about it? ;-) > This advice and these instructions are all fine. However, just for the > record, creating a standalone cpio archive and arranging for the > bootloader to load the kernel and cpio archive into DRAM as separate > images before booting the kernel is not solving the same problem as > embedding a cpio archive inside the kernel image via OE's > INITRAMFS_IMAGE_BUNDLE option. Another excellent observation! I do create test creations, mainly test vehicles for the boards/platforms these days. And for this, better to have splited zImage and initramfs.cpio.xz. The reason is very obvious: this is the scalability problem, and sometimes I need/require to swap parts in this equation! If the final production image is to be prepared, especially for final static rootfs-es with well defined applications on hard drives, the bundle (kernel+initramfs) will be just fine/excellent transient solution! Zoran ___ On Fri, Jul 6, 2018 at 3:13 AM, Andre McCurdy wrote: > On Wed, Jul 4, 2018 at 11:23 PM, Zoran Stojsavljevic > wrote: >> Hello to all, >> >> I have my own YOCTO recipe how I do the initramfs. >> >> Usually, some of these are missing in kernel .config file: >> >> CONFIG_BLK_DEV_INITRD=y >> CONFIG_RD_GZIP=y >> CONFIG_RD_BZIP2=y >> CONFIG_RD_LZMA=y >> CONFIG_RD_XZ=y >> CONFIG_RD_LZO=y >> CONFIG_RD_LZ4=y >> >> Please, check (they should be on) the CONFIG_DECOMPRESS_* options and if >> not, please, turn them on. >> >> To do this, please, for YOCTO use the following (to reconfigure kernel >> .config): >> bitbake -c menuconfig virtual/kernel >> >> Also, in the local.conf I have the following set: >> >> DISTRO_FEATURES_append = " ram" > > There is no standard distro feature called "ram". Perhaps this is > something specific to your BSP layer? > >> IMAGE_FSTYPES_append = " cpio.xz" >> >> Then I do: bitbake -k core-image-minimal, and from: >> .../build/tmp/tmp/deploy/images/ >> >> Take my .cpio.xz as initramfs. Also, I take accordingly >> zImage and .dtb files as well. >> >> I prepend to initramfs.cpio.xz u-boot header: >> mkimage -n 'Ramdisk Image' -A arm -O linux -T ramdisk -C gzip -d >> initramfs.cpio.xz initramfs.cpio.xz.uboot >> >> And then write tiny U-Boot ash script to tftp (from host) all three files to >> the target platform. > > This advice and these instructions are all fine. However, just for the > record, creating a standalone cpio archive and arranging for the > bootloader to load the kernel and cpio archive into DRAM as separate > images before booting the kernel is not solving the same problem as > embedding a cpio archive inside the kernel image via OE's > INITRAMFS_IMAGE_BUNDLE option. > >> On Wed, Jul 4, 2018 at 8:57 PM, Ferry Toth wrote: >>> >>> Tim Hammer wrote: >>> >>> > Can anyone point me to a step-by-step tutorial or simple how-to on >>> > creating and using an initramfs with my kernel for ARM aarch64? >>> > >>> > >>> > I have tried creating my own: >>> > - boot-image.bb file with IMAGE_FSTYPES = "cpio.gz". >>> > - local.conf has INITRAMFS_IMAGE_BUNDLE = "1" >>> > - linux.bbappend has INITRAMFS_IMAGE = "boot-image" >>> > >>> > This all seems to be "correct" to the extent that bitbake linux tries to >>> > do the right thing. >>> > >>> > However, I get a failure in do_bundle_initramfs- "mv: cannot stat >>> > 'arch/arm64/boot/Image': No such file or directory". >>> > >>> > To the best of my (limited) debugging abilities with Yocto, it seems >>> > like >>> > the kernel image backup has already been run when it gets to this point >>> > and the Image file in that directory has already been moved to >>> > Image.bak. >>> > If I comment out the mv statement in kernel.bbclass causing the failure, >>> > the process continues, but the initramfs does not seem to get populated >>> > or >>> > perhaps installed into my kernel image as I get kernel panics that I >>> > have >>> > been unable to get past. >>> > >>> > >>> > I decided to take a different approach and try using the >>> > core-image-minimal-initramfs recipe as INITRAMFS_IMAGE. By commenting >>> > out >>> > the COMPATIBLE_HOST entry I am able to build a kernel for ARM aarch64. I >>> > can even seem to boot into this initramfs- it counts down waiting for >>> > removable media; seems to find my primary rootfs on sda3, but there is >>> > no >>> > rootfs.img file there so says it is dropping to a shell (although I >>> > never >>> > get a prompt...). >>> >>> We have taken this approach here >>> >>> https://github.com/edison-fw/meta-intel-edison/tree/master/meta-intel-edison-distro/recipes-core >>> >>> There are 2 images, the rootfs and the
