[YOCTO #3867] bastille -l now reports existing configuration file paths even if it has not previously been run. Previously, it exited with an error if it detected an absence of log files indicating a

[YOCTO #3867] Adds four additional small patches which address miscellaneous small problems in Bastille. The four patches are: fix_missing_use_directives.patch: A number of use directives were

[YOCTO #3867] Renames existing patches and removes some changes. Curses-and-IOLoader-changes.patch is renamed to call_output_config.patch. The new patch omits the removal of the pruning step in

The patches in this set consist of a number of actual bug fixes and a few enhancements. The two enhancements are: 1) A change in the semantics of the -l flag so that it lists configuration files even

Am 25.08.2013 17:03, schrieb Zafrullah Syed: The tar should be in the "${WORKDIR}/git" directory but it will not work as you don't tell bitbake to unpack it. You

Hi Stefan, I updated my recipe: DESCRIPTION = "cameracapture application" SECTION = "examples" LICENSE = "CLOSED" PR = "r0" DEPENDS = "opencv" SRC_URI =

Hi Bruce, Yes, I'm currently working off master. If I add the following qemuarmhf.conf file, and apply the patch to linux-yocto_3.8.bb, it still tries to compile linux-yocto_3.4.bb recipe. You should

Are you working off master ? Since you set the compatibility, it should have been picked. But something else must be changed in your layers, since if you didn't add 3.4 compatibility via bbappends,

Hi Bruce, Ok, I forgot about that! Another quick question, why is it that when I create a new qemuarmhf.conf machine configuration, it doesn't automatically pick up the latest linux-yocto_3.8.bb

I have asked this question in the Gumstix-Users mailing list before, but got no reply.. So just checking out here..! Why does Yocto include 3.5.0/ kernel folder too in the lib/modules/ directory,

Try 3.8%, you need to match on the version completely, and it is 3.8...., not just 3.8. Bruce -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"

Weird, even after setting PREFERRED_VERSION_virtual/linux ="3.8", it still picks up linux-yocto_3.4.bb recipe! What am I failing to set or configure additionally to get it to work, as intended? Best

Hi, I created a new qemuarmhf.conf, to build using armv7a vfp and neon. In the linux-yocto_3.8.bb recipe, I explicitly specified SRCREV_machine_qemuarmhf and added qemuarmhf to the list of

The above is a workaround, the proper fix is to track down why this is making its way in there in the first place and fix the problem at source. Cheers, Richard

This sounds like a bug to me. It would be best if you file it as such with bugzilla so it gets looked at properly (I'm not the one to do that, sorry) --

Yes I think everyone is seeing it, but in many distro configs bad RPATH is only QA warning not error (that's why I was partially ignoring it until now, concentrating on other issues). You can see

Hi, I'm trying to build a QEMU machine configuration with support for ARM Cortex A9, with hard float and neon support. What should I specify in my qemuarmhf.conf machine file to enable a

<trevor.woerner@...> wrote: Try adding a .bbappend with the following content: ################# DEPENDS += "chrpath-replacement-native" EXTRANATIVEPATH += "chrpath-native" PRINC :=

Check the compile logs. Somewhere, something is passing a -rpath value to the linker which results in this. You'll have to find out where it gets passed in, then trace it back to the source of the

I found the answer to this, the qemu images are located with the meta-toolchain-sdk, so copy over the generated kernel and rootfilesystem (ext3) images to the new machine, installing the toolchain SDK