The past few weeks ftp://ftp.gnu.org has been intermittently giving errors like this:

WARNING: Failed to fetch URL ftp://ftp.gnu.org/gnu/emacs/emacs-23.4.tar.gz;name=tarball, attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 4, output:
Cannot parse PASV response.
accept: Connection timed out
Cannot parse PASV response.
Error in server response, closing control connection.

Which is annoying because binutils lives there. Using http://ftp.gnu.org hasn't given any problems so far.

Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Add BBLAYERS_LAYERINDEX_URL variable that bitbake-layers can use to find layer index.
Add BBLAYERS_FETCH_DIR variable that bitbake-layers can use to specify fetch directory.

[YOCTO #5348]

Signed-off-by: Chong Lu <Chong.Lu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

It turns out that changing WARN_QA and ERROR_QA results in do_configure's QA
postfunc re-executing, so changing a QA test results in a complete rebuild.

This is just too much and the lesser evil of needing to do a full rebuild to
verify changed QA flags is preferable to an enforced full rebuild.

This reverts commit daecfc3438122b5d146a59a5053e57006d55ccc4.

Signed-off-by: Ross Burton <ross.burton@intel.com>

Changing WARN_QA and ERROR_QA should cause do_package_qa to re-execute, so
removing them from the sstate hashes is harmful.

They were added back when sanity testing was part of packaging and this was the
lesser evil, compared to changing sanity tests causing a re-package of
everything.

Signed-off-by: Ross Burton <ross.burton@intel.com>

In meta/conf/bitbake.conf, PKGDATA_DIR is default to:
PKGDATA_DIR = "${STAGING_DIR_HOST}/pkgdata"

But in meta/conf/multilib.conf, PKGDATA_DIR is set as:
PKGDATA_DIR = "${STAGING_DIR}/${MACHINE}/pkgdata"

When multilib enabled, linux-libc-headers cache will be machine
specific:
$ bitbake-diffsigs sstate-cache/1a/sstate:linux-libc-headers:ppce6500-poky-linux:3.17.7:r0:ppce6500:3:1a0c3934d91479fd7242a5b1d407d155_package.tgz.siginfo sstate-cache/28/sstate:linux-libc-headers:ppce6500-poky-linux:3.17.7:r0:ppce6500:3:28c918e8f9f4a4cfceb3a38b258f7501_package.tgz.siginfo
basehash changed from 8d3158bbddcee612fa30badd05f47b8e to 68ac258fc6c8e489f360fde3123a5894
Variable MACHINE value changed from 'b4420qds' to 'b4860qds'

Signed-off-by: Ting Liu <ting.liu@freescale.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

[YOCTO #7230]

In certain system configurations TRANSLATED_TARGET_ARCH will not
expand in the right order for gcc-cross-candian-mips64n32 to be
generated properly.

This will cause SDKs to fail to generate properly.

Changing the global definition of TRANSLATED_TARGET_ARCH always
expands the ABIEXTENSION, which causes the OVERRIDES to pick it up
as well.  This effectively defines a new class of overrides for the 'n32'.

The side effect is that we need to duplicate some mips64 overrides, and
redefine others that were previously 'n32' or 'mips64' exclusive to have
the correct semantics.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>

commit 3b3f7e785e279 [kernel: Rearrange for 1.8] began the process of
moving the kernel source and build artefacts out of sstate control and
into a shared location.

This changed triggered some workflow issues, as well as bugs related
to the kernel source containing build output, and hence being dirty and
breaking kernel rebuilds.

To solve these issues, and to make it clear that the kernel is not under
sstate control, we move the source and build outputs to:

  work-shared/MACHINE/kernel-source
  work-shared/MACHINE/kernel-build-artifacts

Where kernel-build-artifacts is the kernel build output and
kernel-source is kept "pristine". The build-artifacts contain everything
that is required to build external modules against the kernel source,
and includes the defconfig, the kernel-abiversion, System.map files and
output from "make scripts".

External module builds should either pass O= on the command line, or
set KBUILD_OUTPUT to point to the build-artifacts. module-base.bbclass
takes care of setting KBUILD_OUTPUT, so most existing external module
recipes are transparently adapted to the new source/build layout.

recipes that depend on the kernel source must have a depedency on the
do_shared_workdir task:

 do_configure[depends] += "virtual/kernel:do_shared_workdir"

With this dependency added, the STAGING_KERNEL_DIR will be populated and
available to the rest of the build.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

As the code that uses BB_SIGNATURE_EXCLUDE_FLAGS uses d.getVarFlags() so doesn't
get to see the internal flags, remove _append and _prepend.  Also defaultval is
now _defaultval and thus internal, so remove that too.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Recipe packaging for the target requires permissions that are consistent
with meta/files/fs-perms.txt which specifies certain user and group
names.  In the early parts of a target build base-passwd is not yet
available to provide the target /etc files used for user/group lookup.
Allow pseudo to fall-back to the last-resort files it installs if the
target ones aren't there yet.

Signed-off-by: Peter A. Bigot <pab@pabigot.com>

Instead of replicating the logic for the host compiler naming from bitbake.conf,
use the BUILD_* variables directly.

Also change BUILD_CPP to use gcc -E (which native.bbclass previously used), as
some recipes (e.g. grub-efi) use ${CPP} with multiple input files, which gcc -E
can handle but cpp can't.

Signed-off-by: Ross Burton <ross.burton@intel.com>