Re: [yocto] bitbake -c populate_sdk -v poky-image
On Thursday 29 August 2013 10:11:31 Navani Srivastava wrote: > In order to execute > "bitbake -c populate_sdk poky-image" are we supposed to declare > BUILD_ARCH or SDK_ARCH somewhere in local.conf file? > Yocto Documentation has not mentioned anything like that. Just a doubt as > "bitbake poky-image" is working fine though populate_sdk is giving problem.. You should set SDKMACHINE if you need the machine that runs the SDK to be a different architecture from the machine that you're running the build on, otherwise it will just use the same one. We're aware the documentation is lacking on -c populate_sdk, and we're addressing that in the documentation for the next release. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake -c populate_sdk -v poky-image
>>You should set SDKMACHINE if you need the machine that runs the SDK to be a different architecture from the machine Please find the local.conf file which clearly shows SDKMACHINE is i686 and I want to build for arm1136 arch.. So MACHINE ??= "EBboard" is given where EBboard refers to arm1136 architecture.. Not able to find any problem in configurations.. /opt/poky/1.3.2/sysroots/i686-pokysdk-linux/usr/bin/armv6-vfp-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc test.c test.c:3:19: fatal error: stdio.h: No such file or directory error shows that I have problem in cross toolchain... Have yocto ever faced such kind of issue with populate_sdk before ? On Thu, Aug 29, 2013 at 1:43 PM, Paul Eggleton < paul.eggle...@linux.intel.com> wrote: > On Thursday 29 August 2013 10:11:31 Navani Srivastava wrote: > > In order to execute > > "bitbake -c populate_sdk poky-image" are we supposed to declare > > BUILD_ARCH or SDK_ARCH somewhere in local.conf file? > > Yocto Documentation has not mentioned anything like that. Just a doubt as > > "bitbake poky-image" is working fine though populate_sdk is giving > problem.. > > You should set SDKMACHINE if you need the machine that runs the SDK to be a > different architecture from the machine that you're running the build on, > otherwise it will just use the same one. > > We're aware the documentation is lacking on -c populate_sdk, and we're > addressing that in the documentation for the next release. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > local.conf Description: Binary data ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake -c populate_sdk -v poky-image
On Thursday 29 August 2013 13:57:12 Navani Srivastava wrote: > >>You should set SDKMACHINE if you need the machine that runs the SDK to be > > a > different architecture from the machine > Please find the local.conf file which clearly shows SDKMACHINE is i686 and > I want to build for arm1136 arch.. So MACHINE ??= "EBboard" is given where > EBboard refers to arm1136 architecture.. > Not able to find any problem in configurations.. OK. I think it's unlikely that that would be able to cause this kind of problem anyway. > /opt/poky/1.3.2/sysroots/i686-pokysdk-linux/usr/bin/armv6-vfp-poky-linux-gnu > eabi/arm-poky-linux-gnueabi-gcc test.c > test.c:3:19: fatal error: stdio.h: No such file or directory > > error shows that I have problem in cross toolchain... Have yocto ever > faced such kind of issue with populate_sdk before ? Not that I'm aware of. Could you please file a bug in bugzilla for this? It would really help if you had a simple test case we can use to reproduce it with the SDK as well. Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] confusion about DEPENDS vs RDEPENDS
Hi Hans,
On Wednesday 28 August 2013 21:22:36 Hans Beckerus wrote:
> On 2013-08-28 6:06, Paul Eggleton wrote:
> > On Wednesday 28 August 2013 17:08:41 Hans Beckérus wrote:
> >> Hi, I am a little bit confused about how to handle these two and what
> >> they are supposed to solve. I have so far never used RDEPENDS but only
> >> DEPENDS.
> >
> > DEPENDS means a build-time dependency i.e. between recipes, RDEPENDS means
> > a runtime dependency i.e. between packages. It is worth noting though
> > that an explicitly stated RDEPENDS will cause bitbake to actually build
> > the recipe providing the package named in the RDEPENDS value, just at a
> > different time. To explain exactly what each of these do:
> >
> > * DEPENDS = "b" in recipe "a" will translate to a's do_configure task
> > depending on recipe b's do_populate_sysroot task, so that anything recipe
> > b puts into the sysroot is available for when a configures itself.
> >
> > * RDEPENDS_${PN} = "b" in recipe "a" will translate to a's do_build task
> > depending on recipe b's do_package_write task, so that the package file b
> > is available when the output for a has been completely built (of course
> > assuming that recipe b produces a package called "b", which it will with
> > the default value of PACKAGES). More importantly it will also ensure that
> > package "a" is marked as depending on "b" in a manner understood by the
> > package manager being used e.g. rpm / opkg / dpkg.
>
> Thanks a lot! This was definitely more than I got from the description
> of DEPENDS and RDEPENDS in the manual.
> But I probably just read the wrong one ;)
We probably should explain things to that level, I'm fairly sure we don't at
the moment. I'll talk to Scott to see if we can work something like the above
into the manual.
> > By default, if recipe "foo" changes and it is mentioned in the "someapp"
> > recipe's DEPENDS, then someapp's do_configure and all tasks that depend
> > upon it will be re-executed next time it is called for i.e. you
> > explicitly build someapp or build an image that contains it or some other
> > recipe that depends upon it. The fact that you are getting the behaviour
> > described suggests that this is either not happening, or more likely it
> > is not having the desired effect; e.g. if internally someapp's build
> > system doesn't drop or invalidate all of its build output when it is
> > reconfigured then you will get this kind of behaviour. Setting up B (the
> > directory in which a recipe's source code is built) separate to S (the
> > directory in which the recipe's source code has been unpacked to) can
> > help with this since if they are separate, our build system will know it
> > can delete B before re-executing do_compile after do_configure and you'll
> > never have stale build output. Being able to set this up however is
> > highly dependent on the software being built by the individual recipe;
> > some lend themselves to this and others don't.
>
> Well, I have been struggling before with packages not properly
> supporting different build and source folders so I can definitely relate
> to what you are saying. But, does that mean I actually *have* to do it
> this way for build dependencies to work correctly?
I wouldn't have thought so, to be honest I'm just positing one situation where
I can see how this kind of thing might be able to happen. Either do_configure,
do_compile etc. are not re-executing (and by default they should - *if* the
build system has a means to know about the change you have made), or they are
re-executing but the re-execution didn't materially change the output,
certainly not to the point where it linked against the new library version. It
would be pretty easy to figure out which of the two happened by looking at task
logs - either you'd see no extra task logs or you'd see in the latest
do_compile/do_configure log that nothing much was being done.
> In my case we are talking two simple autotools enabled packages and I
> (naively?) assumed this was not something I had to take care of myself.
In the ideal case it should not be.
> What strikes me is that you say ""if recipe "foo" changes"", which is
> actually not the case here! What is changed is the actual source code only.
> Is that what is going wrong here? If I change my "foo" recipe version, would
> that be different than to simply fetch/unpack the "foo" package source code?
> Is "someapp" going to become purged differently in such a scenario?
OK, so just to make sure I understand what changes you are making - are you
changing configuration/recipes/files pointed to in SRC_URI at all, or just
modifying the unpacked source in the recipe's work directory?
> What is still somewhat unclear to me is the difference between DEPENDS
> and RDEPENDS in a simple case as this. A simple application needing a
> dynamic library is obviously a subject for DEPENDS but to me that also
> sounds like a typical RDEPENDS?
>
> However, when I build an image an
Re: [yocto] confusion about DEPENDS vs RDEPENDS
Hi Paul,
On Thu, Aug 29, 2013 at 10:58 AM, Paul Eggleton
wrote:
> Hi Hans,
>
> On Wednesday 28 August 2013 21:22:36 Hans Beckerus wrote:
>> On 2013-08-28 6:06, Paul Eggleton wrote:
>> > On Wednesday 28 August 2013 17:08:41 Hans Beckérus wrote:
>> >> Hi, I am a little bit confused about how to handle these two and what
>> >> they are supposed to solve. I have so far never used RDEPENDS but only
>> >> DEPENDS.
>> >
>> > DEPENDS means a build-time dependency i.e. between recipes, RDEPENDS means
>> > a runtime dependency i.e. between packages. It is worth noting though
>> > that an explicitly stated RDEPENDS will cause bitbake to actually build
>> > the recipe providing the package named in the RDEPENDS value, just at a
>> > different time. To explain exactly what each of these do:
>> >
>> > * DEPENDS = "b" in recipe "a" will translate to a's do_configure task
>> > depending on recipe b's do_populate_sysroot task, so that anything recipe
>> > b puts into the sysroot is available for when a configures itself.
>> >
>> > * RDEPENDS_${PN} = "b" in recipe "a" will translate to a's do_build task
>> > depending on recipe b's do_package_write task, so that the package file b
>> > is available when the output for a has been completely built (of course
>> > assuming that recipe b produces a package called "b", which it will with
>> > the default value of PACKAGES). More importantly it will also ensure that
>> > package "a" is marked as depending on "b" in a manner understood by the
>> > package manager being used e.g. rpm / opkg / dpkg.
>>
>> Thanks a lot! This was definitely more than I got from the description
>> of DEPENDS and RDEPENDS in the manual.
>> But I probably just read the wrong one ;)
>
> We probably should explain things to that level, I'm fairly sure we don't at
> the moment. I'll talk to Scott to see if we can work something like the above
> into the manual.
>
Great! Your input has been really helpful.
>> > By default, if recipe "foo" changes and it is mentioned in the "someapp"
>> > recipe's DEPENDS, then someapp's do_configure and all tasks that depend
>> > upon it will be re-executed next time it is called for i.e. you
>> > explicitly build someapp or build an image that contains it or some other
>> > recipe that depends upon it. The fact that you are getting the behaviour
>> > described suggests that this is either not happening, or more likely it
>> > is not having the desired effect; e.g. if internally someapp's build
>> > system doesn't drop or invalidate all of its build output when it is
>> > reconfigured then you will get this kind of behaviour. Setting up B (the
>> > directory in which a recipe's source code is built) separate to S (the
>> > directory in which the recipe's source code has been unpacked to) can
>> > help with this since if they are separate, our build system will know it
>> > can delete B before re-executing do_compile after do_configure and you'll
>> > never have stale build output. Being able to set this up however is
>> > highly dependent on the software being built by the individual recipe;
>> > some lend themselves to this and others don't.
>>
>> Well, I have been struggling before with packages not properly
>> supporting different build and source folders so I can definitely relate
>> to what you are saying. But, does that mean I actually *have* to do it
>> this way for build dependencies to work correctly?
>
> I wouldn't have thought so, to be honest I'm just positing one situation where
> I can see how this kind of thing might be able to happen. Either do_configure,
> do_compile etc. are not re-executing (and by default they should - *if* the
> build system has a means to know about the change you have made), or they are
> re-executing but the re-execution didn't materially change the output,
> certainly not to the point where it linked against the new library version. It
> would be pretty easy to figure out which of the two happened by looking at
> task
> logs - either you'd see no extra task logs or you'd see in the latest
> do_compile/do_configure log that nothing much was being done.
>
>> In my case we are talking two simple autotools enabled packages and I
>> (naively?) assumed this was not something I had to take care of myself.
>
> In the ideal case it should not be.
>
>> What strikes me is that you say ""if recipe "foo" changes"", which is
>> actually not the case here! What is changed is the actual source code only.
>> Is that what is going wrong here? If I change my "foo" recipe version, would
>> that be different than to simply fetch/unpack the "foo" package source code?
>> Is "someapp" going to become purged differently in such a scenario?
>
> OK, so just to make sure I understand what changes you are making - are you
> changing configuration/recipes/files pointed to in SRC_URI at all, or just
> modifying the unpacked source in the recipe's work directory?
>
It is the source code in the source repo that has changed. I.e. before
the change the repo for
Re: [yocto] confusion about DEPENDS vs RDEPENDS
Hi Paul / Nicolas,
On Wednesday 28 August 2013 15:15:27 Paul D. DeRocco wrote:
> From: Nicolas Dechesne
> > if the source code changes, the version of the recipe needs
> > to change too. if you change the source code without bumping
> > the version, the package might not be rebuilt properly
> > indeed. and that can explain the behavior you are seeing. if
> > 'someapp' does not change, it would be rebuilt only if one of
> > its dependencies was rebuilt.
>
> If you're making lots of changes in the course of debugging, isn't it
> reasonable just to do a cleansstate on the recipe to force it to be
> rebuilt?
Current versions of the build system (denzil/1.2+, although refinements have
been made since then) are task signature-based. That means as far as the build
system is able to determine its inputs, if those change it should be able to
rebuild all of the output to match. Known limitations:
* Upstream software that doesn't properly rebuild when reconfigured. In most
cases this should be considered as a bug in the recipe. Separating S from B
can help here as I mentioned earlier, and you can see in dylan/1.4+ in
meta/conf/distro/include/seperatebuilddir.inc that we've been enabling
separate recipe build dirs for a number of recipes to help with this.
* Editing the unpacked/patched source code in the recipe's work directory
(i.e. tmp/work/...). Note that this is not something that is discouraged - in
fact it can be a very useful development aid. However, you do need to be aware
of the need to force the appropriate tasks to re-execute after you have made
changes in there i.e. bitbake -c compile -f or bitbake -C compile
, since the build system cannot detect these kinds of changes on its
own.
* Items remaining in the sysroot when recipes are completely renamed (i.e.
when PN changes) or when a recipe is removed. We saw this recently with the
mesa-dri -> mesa rename. Currently there's no way for the system to know what
replaces what when PN changes or what to do when a recipe completely vanishes,
you just have to clean out the old recipe's files in the sysroot. This can of
course happen if you add and remove layers without deleting TMPDIR, so care
should be taken when doing that. This is an difficult issue to solve
practically; there is discussion of this issue here for those interested:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4102
* If you use runtime packaging ("package-management" in IMAGE_FEATURES) and
you're putting the packages into a feed and expect on-target upgrades to work
consistently from those feeds without manually bumping PR in recipes on every
material change, you need to enable the PR service as described in the
development manual so that PR increments automatically.
* Changes on the host system affecting native recipes - less likely to cause
issues, but worth being aware of. It can happen that adding or removing
packages on the host system changes the configuration of native recipes without
automatically triggering a rebuild - a good example is how we allow qemu-
native to build on systems with and without X11; if you added SDL and X11 to a
system on which you'd already built qemu-native beforehand, in the absence of
other changes you'd have to cleansstate or otherwise force a rebuild of qemu-
native to have a native QEMU that supported graphical output.
However, with the caveats above, most of the time you can rely upon the build
system to determine what to do when things change. Of course, yes, if you want
to just force a recipe to rebuild you have the option of bitbake -c
cleansstate before building it again, but most of the time that's
going to be more than is needed.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Lighttpd web server on BlueGiga's APx4 development board
Hi, I am using BlueGiga's APx4 development board which have Yocto BSP. It have Lighttpd web-server configured. I have seen that Lighttpd web-server on Yocto BSP uses cgi-bin and .json scripts for HTML. I would like to use cgi-bin and .xml tags for HTML. I visited Yocto's GIT server but didn't got any thing. I only got configuration files of Lighttpd, I neither got any thing related to cgi-bin, .xml or .json. So, Yocto have any BSP which uses cgi-bin and .xml tags for HTML instead of cgi-bin and .json scripts for HTML? OR a web-server configure to use cgi-bin and .xml tags? Thanks and Regards, Vinayak Garad - Notice: This message has been scanned by Trend Micro Mail Security scanner and is believed to be clean - ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] yocto-bsp and kconf-check
It appears that the yocto-bsp script generates a kernel configuration that
creates some warnings during kern-tools' kconf_check. The {{machine}}.cfg file
has many non-hardware options, therefore the script warns.
It seems like many of these should be in the standard kernel configuration. Is
this correct, and does the yocto-bsp data need to be updated?
- Jate
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto-bsp and kconf-check
On 13-08-29 11:36 AM, Jate Sujjavanich wrote:
It appears that the yocto-bsp script generates a kernel configuration that
creates some warnings during kern-tools' kconf_check. The {{machine}}.cfg file
has many non-hardware options, therefore the script warns.
It seems like many of these should be in the standard kernel configuration. Is
this correct, and does the yocto-bsp data need to be updated?
Which kernel version ? But the answer is not necessarily, if a machine
config
is specifying something that hasn't been tagged "hardware" or that
has a specified exception, you get a warning.
It's not about them being common or not, it's about BSPs following a
base policy versus having wild, per-board behaviour.
Cheers,
Bruce
- Jate
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Partitioned Image Creation and Initramfs Problem for ALIX3D3
Hello all, As you may already know, I have been working on a BSP for ALIX3D3[0]. I enabled specific kernel configurations and reached to the point of booting the board with its features enabled. I can boot the board with "live" image type. However, what I want to have is a direct partitioned hdd image which we can dd it into CF Card. So, /dev/sda1 will contain kernel and initrd, /dev/sda2 will contain extracted rootfs. I expect / to be mounted to /dev/sda2. Currently, live image extracts the rootfs to /dev/ram0 and the configuration is gone after reboot. I looked at the existing solutions and found out that "boot-directdisk.bbclass", which is inherited by image-vmdk, does a similar job. However, it does not include initramfs image and it looks like it was specifically written to enable vmdk image, not for this purpose. The possible solution that came to my mind is to get "boot-directdisk.bbclass", add initramfs installation, put the code in a seperate bbclass, rename the function as IMAGE_CMD_alix-hddimage, and add "alix-hddimage" to IMAGE_FSTYPES. The same technique is used by meta-raspberrypi layer [1] However, the problem with this is that "core-image-minimal-initramfs" includes "initramfs-live-boot" by default. This script tries to find rootfs.img and if it cannot find, it fails to boot the board. In this case, we will have extracted rootfs in /dev/sda2, so rootfs.img will not be there. I looked at "initramfs-framework" recipe and it seems to fit for it. For initramfs problem, should I create "alix3d3-minimal-initramfs" recipe, add "initramfs-framework-base initramfs-module-udev" to IMAGE_INSTALL and make "IMAGE_CMD_alix-hddimage" depend on "alix3d3-minimal-initramfs"? Would it be a proper solution? I am stuck here. Any help is appreciated especially on partitioning the image and copying. My best regards, Eren [0] https://github.com/eren/meta-alix3d3 [1] http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi -- . 73! DE TA1AET http://linkedin.com/in/erenturkay pgpsXcwiQcsfn.pgp Description: PGP signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] OE recipes- linphone build error in poky-9.0.0 build environment
Thanks for replay, I have follow the steps suggested by Mr. Paul, but still i am facing an error. I wants to build the linphone along with my Yocto Project build environment setup. I found linphone recipes in openembedded git. I have added that recipe and also add the dependancy recipes libosip2 and also modify .bb files. But still i am getting build error. // Loading cache: 100% |#| ETA: 00:00:00 Loaded 1128 entries from dependency cache. Build Configuration: BB_VERSION= "1.18.0" BUILD_SYS = "i686-linux" NATIVELSBSTRING = "Ubuntu-12.04" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "qemuarm" DISTRO= "poky" DISTRO_VERSION= "1.4" TUNE_FEATURES = "armv5 thumb dsp" TARGET_FPU= "soft" meta meta-yocto meta-yocto-bsp meta-linphone = ":" NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: Fetcher failure for URL: 'http://download.savannah.nongnu.org/releases/linphone/1.6.x/sources/linphone-1.6.0.tar.gz'. No checksum specified for /home/yocto/YOCTO/poky-dylan-9.0.0/build/downloads/linphone-1.6.0.tar.gz, please add at least one to the recipe: SRC_URI[md5sum] = "fb345125e23c787df0818ff7caad5515" SRC_URI[sha256sum] = "ba1c32207fd62d374c9397a81fb1247da93edb859e30d0d855dc65e5457f690b" ERROR: Function failed: Fetcher failure for URL: 'http://download.savannah.nongnu.org/releases/linphone/1.6.x/sources/linphone-1.6.0.tar.gz'. No checksum specified for /home/yocto/YOCTO/poky-dylan-9.0.0/build/downloads/linphone-1.6.0.tar.gz, please add at least one to the recipe: SRC_URI[md5sum] = "fb345125e23c787df0818ff7caad5515" SRC_URI[sha256sum] = "ba1c32207fd62d374c9397a81fb1247da93edb859e30d0d855dc65e5457f690b" ERROR: Logfile of failure stored in: /home/yocto/YOCTO/poky-dylan-9.0.0/build/tmp/work/armv5te-poky-linux-gnueabi/linphone/1.6.0-r3/temp/log.do_fetch.3098 ERROR: Task 358 (/home/yocto/YOCTO/poky-dylan-9.0.0/meta-linphone/recipes-linphone/linphone/linphone_1.6.0.bb, do_fetch) failed with exit code '1' ERROR: libosip2: Recipe file does not have license file information (LIC_FILES_CHKSUM) ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix ERROR: Function failed: do_qa_configure ERROR: Logfile of failure stored in: /home/yocto/YOCTO/poky-dylan-9.0.0/build/tmp/work/armv5te-poky-linux-gnueabi/libosip2/3.5.0-r0/temp/log.do_configure.3078 ERROR: Task 1024 (/home/yocto/YOCTO/poky-dylan-9.0.0/meta-linphone/recipes-linphone/libosip2/libosip2_3.5.0.bb, do_configure) failed with exit code '1' NOTE: Tasks Summary: Attempted 4749 tasks of which 4747 didn't need to be rerun and 2 failed. Waiting for 0 running tasks to finish: Summary: 2 tasks failed: // Do anyone knows how to fix the LIC_FILES_CHKSUM for libosip2 .bb file or linphone .bb file. Please suggest me how to fix this error. Thanks & Regards Amit K. From: Paul Eggleton [paul.eggle...@linux.intel.com] Sent: Wednesday, August 28, 2013 1:43 PM To: Amit Kumar Cc: yocto@yoctoproject.org Subject: Re: [yocto] OE recipes- linphone build error in poky-9.0.0 build environment Hi Amit, On Wednesday 28 August 2013 09:05:28 Amit Kumar wrote: > I wants to build the recipes name linphone(SIP-based IP phone) with > poky-9.0.0 build environment. I found he linphone recipes under the > "angstrom-openembedded". In my poky build environment I have created the > new layer, name linphone, and copy the .bb files. But when i am building it > through an dependency error. > > Do anyone have done it before, please guide me how to fix this error. > > > yocto@yocto-HP:~/YOCTO/poky-dylan-9.0.0/build$ bitbake > linphone-image Loading cache: 100% > |## > ###| ETA: 00:00:00 Loaded 1126 entries from dependency > cache. > > Build Configuration: > BB_VERSION= "1.18.0" > BUILD_SYS = "i686-linux" > NATIVELSBSTRING = "Ubuntu-12.04" > TARGET_SYS= "arm-poky-linux-gnueabi" > MACHINE = "qemuarm" > DISTRO= "poky" > DISTRO_VERSION= "1.4" > TUNE_FEATURES = "armv5 thumb dsp" > TARGET_FPU= "soft" > meta > meta-yocto > meta-yocto-bsp > meta-linphone = ":" > > NOTE: Resolving any missing task queue dependencies > ERROR: Nothing PROVIDES 'libosip2' (but > /home/yocto/YOCTO/poky-dylan-9.0.0/meta-linphone/recipes-linphone/linphone/ > linphone_1.6.0.bb DEPENDS on or otherwise requires it) NOTE: Runtime target > 'linphone' is unbuildable, removing... > Missing or unbuildable dependency chain was: ['linphone', 'libosip2'] > ERROR: Required build target 'linphone-image' has no buildable providers. >
Re: [yocto] yocto-bsp and kconf-check
> Which kernel version ?
This is linux-yocto-3.8 and the dylan-9.0.0 yocto.
> It's not about them being common or not, it's about BSPs following a
> base policy versus having wild, per-board behaviour.
I've cleaned up many items from the yocto-bsp generated {{machine}}.cfg that
are already added by KTYPE. I have two remaining warnings for CONFIG_NET and
CONFIG_NETDEVICES. Nested includes eventually lead to the line
force kconf non-hardware base.cfg
which adds those config options. I thought the non-hardware would prevent the
specified_non_hdw.cfg warning.
Any ideas?
> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Thursday, August 29, 2013 11:52 AM
> To: Jate Sujjavanich
> Cc: 'yocto@yoctoproject.org'
> Subject: Re: [yocto] yocto-bsp and kconf-check
>
> On 13-08-29 11:36 AM, Jate Sujjavanich wrote:
> > It appears that the yocto-bsp script generates a kernel configuration
> that creates some warnings during kern-tools' kconf_check. The
> {{machine}}.cfg file has many non-hardware options, therefore the script
> warns.
> >
> > It seems like many of these should be in the standard kernel
> configuration. Is this correct, and does the yocto-bsp data need to be
> updated?
>
> Which kernel version ? But the answer is not necessarily, if a machine
> config is specifying something that hasn't been tagged "hardware" or
> that has a specified exception, you get a warning.
>
> It's not about them being common or not, it's about BSPs following a
> base policy versus having wild, per-board behaviour.
>
> Cheers,
>
> Bruce
>
> >
> > - Jate
> > ___
> > 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] yocto-bsp and kconf-check
On 13-08-29 02:56 PM, Jate Sujjavanich wrote:
Which kernel version ?
This is linux-yocto-3.8 and the dylan-9.0.0 yocto.
It's not about them being common or not, it's about BSPs following a
base policy versus having wild, per-board behaviour.
I've cleaned up many items from the yocto-bsp generated {{machine}}.cfg that
are already added by KTYPE. I have two remaining warnings for CONFIG_NET and
CONFIG_NETDEVICES. Nested includes eventually lead to the line
force kconf non-hardware base.cfg
which adds those config options. I thought the non-hardware would prevent the
specified_non_hdw.cfg warning.
It should, unless there's a bug. Can you send me the steps to
reproduce the config ? i.e. just your generated BSP layer in a
.tgz should be enough.
Bruce
Any ideas?
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Thursday, August 29, 2013 11:52 AM
To: Jate Sujjavanich
Cc: 'yocto@yoctoproject.org'
Subject: Re: [yocto] yocto-bsp and kconf-check
On 13-08-29 11:36 AM, Jate Sujjavanich wrote:
It appears that the yocto-bsp script generates a kernel configuration
that creates some warnings during kern-tools' kconf_check. The
{{machine}}.cfg file has many non-hardware options, therefore the script
warns.
It seems like many of these should be in the standard kernel
configuration. Is this correct, and does the yocto-bsp data need to be
updated?
Which kernel version ? But the answer is not necessarily, if a machine
config is specifying something that hasn't been tagged "hardware" or
that has a specified exception, you get a warning.
It's not about them being common or not, it's about BSPs following a
base policy versus having wild, per-board behaviour.
Cheers,
Bruce
- Jate
___
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] yocto-bsp and kconf-check
On Thu, 2013-08-29 at 11:36 -0400, Jate Sujjavanich wrote:
> It appears that the yocto-bsp script generates a kernel configuration that
> creates some warnings during kern-tools' kconf_check. The {{machine}}.cfg
> file has many non-hardware options, therefore the script warns.
>
> It seems like many of these should be in the standard kernel configuration.
> Is this correct, and does the yocto-bsp data need to be updated?
>
The templates in yocto-bsp are derived from the reference and qemu BSPs,
and have basically inherited the kernel config from those.
Now that the new kernel has landed, I've started updating the templates
for 3.10, and yes, if all the reference and qemu BSPs have been fixed in
this regard, I need to update the yocto-bsp templates with the new
options as well.
BTW, which arch did you use to generate your BSP?
Tom
> - Jate
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Help with merging files
Hello all, I am a little new to Yocto and bitbake. Could someone please help me with probably some simple concepts that seem to be missing. I would like to build a initramfs image to boot to my device (Freescale i.MX6) I think I need to change the image type to cpio.gz for the output. But my real question is how can I include some external files into that image? I have my application that needs to get bundled into the image. I also have some configuration files as well like init scripts. How would I go about having bitbake include those files when it is creating the initramfs image? I plan to build my application outside of bitbake, and just need it to get wrapped up for me. Remember I am a newbie, so, simple explanation would be great with an example if possible. Thanks Tim ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto-bsp and kconf-check
Some additional information: I noticed that the two CONFIG's are also defined
in the fragment features/usb-net/usb-net.cfg. They are defined without using
the non-hardware flag.
> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Thursday, August 29, 2013 3:45 PM
> To: Jate Sujjavanich
> Cc: 'yocto@yoctoproject.org'
> Subject: Re: [yocto] yocto-bsp and kconf-check
>
> On 13-08-29 02:56 PM, Jate Sujjavanich wrote:
> >> Which kernel version ?
> >
> > This is linux-yocto-3.8 and the dylan-9.0.0 yocto.
> >
> >> It's not about them being common or not, it's about BSPs following a
> >> base policy versus having wild, per-board behaviour.
> >
> > I've cleaned up many items from the yocto-bsp generated
> > {{machine}}.cfg that are already added by KTYPE. I have two remaining
> > warnings for CONFIG_NET and CONFIG_NETDEVICES. Nested includes
> > eventually lead to the line
> >
> > force kconf non-hardware base.cfg
> >
> > which adds those config options. I thought the non-hardware would
> prevent the specified_non_hdw.cfg warning.
>
> It should, unless there's a bug. Can you send me the steps to reproduce
> the config ? i.e. just your generated BSP layer in a .tgz should be
> enough.
>
> Bruce
>
> >
> >
> > Any ideas?
> >
> >> -Original Message-
> >> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> >> Sent: Thursday, August 29, 2013 11:52 AM
> >> To: Jate Sujjavanich
> >> Cc: 'yocto@yoctoproject.org'
> >> Subject: Re: [yocto] yocto-bsp and kconf-check
> >>
> >> On 13-08-29 11:36 AM, Jate Sujjavanich wrote:
> >>> It appears that the yocto-bsp script generates a kernel
> >>> configuration
> >> that creates some warnings during kern-tools' kconf_check. The
> >> {{machine}}.cfg file has many non-hardware options, therefore the
> >> script warns.
> >>>
> >>> It seems like many of these should be in the standard kernel
> >> configuration. Is this correct, and does the yocto-bsp data need to
> >> be updated?
> >>
> >> Which kernel version ? But the answer is not necessarily, if a
> >> machine config is specifying something that hasn't been tagged
> >> "hardware" or that has a specified exception, you get a warning.
> >>
> >> It's not about them being common or not, it's about BSPs following a
> >> base policy versus having wild, per-board behaviour.
> >>
> >> Cheers,
> >>
> >> Bruce
> >>
> >>>
> >>> - Jate
> >>> ___
> >>> 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] Status of 1.5_M4 release candidate.
On Thu, Aug 29, 2013 at 1:42 AM, Flanagan, Elizabeth wrote: > An update on where we are at: > > rc1 is still churning. There was one autobuilder issue with regards to > genericx86 in nightly-x86-lsb. I've built this out by hand and > populated the release with it as well as corrected the ab issue. We're > seeing a lot of sanity issues, but so far no build failures (other > than the above known issue). http://autobuilder.yoctoproject.org/pub/releases/CURRENT/machines/ The imx6*q*sabresd machine has its name mistyped so the built images are not copied. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto-bsp and kconf-check
On 13-08-29 5:39 PM, Jate Sujjavanich wrote:
Some additional information: I noticed that the two CONFIG's are also defined
in the fragment features/usb-net/usb-net.cfg. They are defined without using
the non-hardware flag.
That's could be a contributing factor, if they have their bucket changed
by multiple fragments, the auditing gets harder.
I'll do a run with your BSP and let you know what I find.
Bruce
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Thursday, August 29, 2013 3:45 PM
To: Jate Sujjavanich
Cc: 'yocto@yoctoproject.org'
Subject: Re: [yocto] yocto-bsp and kconf-check
On 13-08-29 02:56 PM, Jate Sujjavanich wrote:
Which kernel version ?
This is linux-yocto-3.8 and the dylan-9.0.0 yocto.
It's not about them being common or not, it's about BSPs following a
base policy versus having wild, per-board behaviour.
I've cleaned up many items from the yocto-bsp generated
{{machine}}.cfg that are already added by KTYPE. I have two remaining
warnings for CONFIG_NET and CONFIG_NETDEVICES. Nested includes
eventually lead to the line
force kconf non-hardware base.cfg
which adds those config options. I thought the non-hardware would
prevent the specified_non_hdw.cfg warning.
It should, unless there's a bug. Can you send me the steps to reproduce
the config ? i.e. just your generated BSP layer in a .tgz should be
enough.
Bruce
Any ideas?
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Thursday, August 29, 2013 11:52 AM
To: Jate Sujjavanich
Cc: 'yocto@yoctoproject.org'
Subject: Re: [yocto] yocto-bsp and kconf-check
On 13-08-29 11:36 AM, Jate Sujjavanich wrote:
It appears that the yocto-bsp script generates a kernel
configuration
that creates some warnings during kern-tools' kconf_check. The
{{machine}}.cfg file has many non-hardware options, therefore the
script warns.
It seems like many of these should be in the standard kernel
configuration. Is this correct, and does the yocto-bsp data need to
be updated?
Which kernel version ? But the answer is not necessarily, if a
machine config is specifying something that hasn't been tagged
"hardware" or that has a specified exception, you get a warning.
It's not about them being common or not, it's about BSPs following a
base policy versus having wild, per-board behaviour.
Cheers,
Bruce
- Jate
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] build stuck at cloning GIT Repo.
My YOcto Project build, The first build is stuck here -- Loading cache: 100% |#| ETA: 00:00:00 Loaded 1181 entries from dependency cache. Build Configuration: BB_VERSION = "1.19.1" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "openSUSE-project-12.3" TARGET_SYS = "arm-poky-linux-gnueabi" MACHINE = "qemuarm" DISTRO = "poky" DISTRO_VERSION = "1.4+snapshot-20130827" TUNE_FEATURES = "armv5 thumb dsp" TARGET_FPU = "soft" meta meta-yocto meta-yocto-bsp = "master:b2ff1add530b1fec2fb7f385227a03db47015c37" NOTE: Resolving any missing task queue dependencies NOTE: multiple providers are available for runtime libasound-module-bluez (bluez4, bluez5) NOTE: consider defining a PREFERRED_PROVIDER entry to match libasound-module-bluez NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks Currently 1 running tasks (1587 of 5917): *0: linux-yocto-3.8.13+gitAUTOINC+e7f42a416a_aa76cc2840-r4.2 do_fetch (pid 2006)* * -- * ** and has been so for the past 4-5 Tries, The size of the GIT2 Directory seems to increase for sometine, The maximum it has gone is 681 MB after which it stopped growing in size, i checked wether my Internet was down, but it was all fine as i started an OpenWRT build along with it and it was downloading its packages smoothly. Is there some problem with the GIT server on the Project Side or my ISP ? How can i know? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
