It is useful to override revision checking from a layer or other
recipe. In order to show the global nature of the variable rename
it KERNEL_REVISION_CHECKING and make it a weak assignment.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Fixes [BUGID #394]
Now that the qemu/mti mips kernel branches have been fixed
for wacom USB interaction, we can re-nable the standard set
of qemu UI options for qemumips.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
OpenSuSE 11.3 uses GNU patch 2.6.1.81-5b68 which breaks quilt's
configure test for patch version.
Signed-off-by: Beth Flanagan <elizabeth.flanagan@intel.com>
Add a test case for error log check with command dmesg in target. The
case introduces a new folder in target, "/opt/test", which holds test
scripts running in target.
Signed-off-by Jiajun Xu <jiajun.xu@intel.com>
Make 3.82, as shipped with Fedora 14, fixes some holes in the parser which in
turn breaks behaviour of some Makefiles. Most notably eglibc's.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
package sstate requires a lock under sysroots/, which however may not be
created when sstate_setscene functions are executed and then causes failures.
here we make sure 'sysroots' created before do_package_setscene is executed.
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
Without doing this I can't reuse prebuilts generated from one directory in another
build directory which is really not comfortable for developers. Due to difference
on PWD variable, base hash becomes different for every sstate package.
So here PWD is added to the hase base whitelist, which makes most prebuilts reusable
now in a different build directory. However there still remains one issue about
do_populate_sysroot sstate package. Absolute path is encoded in this task which
then blocks reuse on them. Perhaps we need some redesign for do_populate_sysroot into
two stages, with all absolute path related operations moved to the 2nd stage. This
way then the 1st stage can be reused.
Partially fix [BUGID #522]
Signed-off-by Kevin Tian <kevin.tian@intel.com>
I created a new sub folder to hold the BSP Guide by itself so there are
three folders now for each of the Yocto manuals: BSP Guide, quick start
and poky ref manual. The new folder for the BSP guide is 'bsp-guide'.
It contains the bsp.xml file, its own Makefile, a bsp-guide.xml file,
and its own 'Figures' directory. The 'bsp-guide.xml' file that was
in the poky reference folder was deleted.
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
I completed general edits to the second chapter of the poky reference
manual. These edits went from section 2.4.5 through the end of the
chapter. They consist of text rewrites for more active voice and follow
general technical writing principles.
I completed the same types of edits in the third chapter of the manual
from the beginning through section 3.3.2.
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Extensive language and consistency edits being applied to the manual.
During the 0.9 push I did not have time to make a pass through the
document.
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Changed "source poky-4.0/poky-init-build-env poky-4.0-build"
to be "source poky-laverne-4.0/poky-init-build-env poky-4.0-build"
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
There was a grammatical error in the title and redundancy in the
first sentence of this section. Cleaned up the title and wording.
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
I did a complete edit pass through this chapter. The manual has
not been fully edited from its original state. One critical technical
correction was corrected where the green-3.3 release was referenced.
I changed this to laverne 4.0.
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
I changed the figure that goes along with building an image based on
Kevin's input. Also, removed several URLs that had 'yoctolinux' in them
along with a 'tar' command example with the same string. LF does
not want these in there.
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
