guile: don't use the identifier 'noreturn'

Fix the build error of autogen-native which depends on guile-native:

ysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:40:24: error: expected ')' before '__attribute__'
sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:40:24: error: expected ',' or ';' before ')' token
sysroots/x86_64-linux/usr/include/guile/2.0/libguile/error.h:42:27: error: expected ')' before '__attribute__'

[YOCTO #5743]

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
linux-firmware: package Marvell SD8797 firmware

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
e2fsprogs/populate-extfs.sh: fix a problem on dash

The dash can't handle the or [[ in parameter expansion, for example:

A=/usr/bin/[[
B=[[
C="${A%$B}"

The C should be "/usr/bin" in common, but it will be /usr/bin/[[ on
dash, use dirname to fix it.

NOTE:
There are 3 lines about parameter expansion, only fix the
DIR="${DIR%$TGT}" since the other 2 works will and are very useful in
this case.

[YOCTO #5712]

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sstate.bbclass: remove previous version's stamp

There is a potential problem if we don't remove the previous version's
stamp, for example:

The depend chain is:
libtool-native -> autoconf-native -> m4-native
We have two m4-native: 1.4.9 and 1.4.7

1) Clean all of them to make a fresh build so that we can reproduce the
   problem
$ bitbake m4-native autoconf-native libtool-native -ccleansstate

2) Build libtool-native so that the m4-native_1.4.17 will be built
$ bitbake libtool-native

3) Set PREFERRED_VERSION_m4-native = "1.4.9" and build again
$ bitbake libtool-native

4) Set PREFERRED_VERSION_m4-native = "1.4.17" and build again
$ bitbake libtool-native -ccleansstate && bitbake libtool-native

Then the build will fail:
[snip]
| m4: unrecognized option '--gnu'
| Try `m4 --help' for more information.
| autom4te: m4 failed with exit status: 1
[snip]

The is because when we change m4-native to 1.4.17 and build
libtool-native again:
5) libtool-native depends on autoconf-native, and autoconf-native's
   version isn't change, so it can remove the current stamp and mirror
   the sstate (the one depends on m4-native_1.4.9) from the SSTATE_DIR
   correctly.

6) The mirrored autoconf-native depends on m4-native_1.4.17's
   do_populate_sysroot, and the stamp is already there (which is made
   by step 2), so it would do nothing, but this is incorrect, since
   the one that really in the sysroot is m4-native_1.4.9, then the
   error happens.

Remove previous version's stamp in sstate_clean() will fix the problem.

[YOCTO #5422]

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
glproto: upgrade to 1.4.17

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

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

Remove spurious libxcb-xinerama addition to PACKAGES, this is handled by the
dynamic split_packages() now.

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

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gdk-pixbuf: don't forcibly disable GIO sniffing, use PACKAGECONFIG.

There's a configure option for GIO sniffing so don't use a patch to disable it.
Instead use a PACKAGECONFIG for this and default to off, as using GIO for
sniffing means a hard dependency on shared-mime-info.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gdk-pixbuf: use PACKAGECONFIG to control loaders with external dependencies

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
unfs3: Add a NFSv3 user mode server for use with runqemu

The user mode nfs server allows the use of runqemu without any root
privileges and may even be accelerated with kvm.

Example:

runqemu-extract-sdk tmp-eglibc/deploy/images/qemux86-64/core-image-minimal-qemux86-64.tar.bz2 rootfs

runqemu qemux86-64 `pwd`/rootfs nographic slirp kvm

[YOCTO #5639]

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
unfs3, unfs-server: Replace all instances of unfs-server with unfs3

Other recipes dependencies and even some comments need to be updated
for the removal of unfs-server and the replacement with unfs3.  The
unfs3 is a complete drop in replacement providing all the prior
functionality of NFSv2 but also adding NFSv3.

[YOCTO #5639]

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
runqemu: Use the newer unfs3 for serving user space nfs

This new version correctly handles the 64bit ext3 / ext4 issues we
were seeing with the older unfs-server which did not handle 64bit file
systems correctly, producing the duplicate cookies.

[YOCTO #5639]

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
unfs-server: Remove unfs-server recipe and patches

The unfs-server only supports NFS v2 and it is not useful any longer
with the advent of 64 bit inodes and the fact that the server has only
a 32 bit key for the NFS hash which is hardcoded back to the inode.

This recipe is replaced with a user mode NFS server using v3.

[YOCTO #5639]

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
runqemu-export-rootfs: update for unfs3

The unfs3 no longer has an rpc.mountd component. There is just a
single server for mountd and nfsd requests.  This means changing
the name of the server in the scripts that check for it.

[YOCTO #5639]

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
runqemu, runqemu-internal: Allow slirp for NFS and KVM use

The default slirp address for the NFS server is 10.0.2.2.  If not
using a tap interface this address must be used or the target system
cannot connect properly.  Also the ip=... kernel arguments need to be
set to dhcp when using slirp or the root NFS will not get setup
properly.

The call to cleanup() results in a routine which is not defined when
setting up the NFS because it is called before acquire() for the
locking of the tap interfaces, the solution being to simply not call
cleanup() that early.

When using slirp, kvm should not execute the vhost net checks because
the vhost net will not be configure or used.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
lib/oeqa: sshcontrol: fix false timeout failures

Ocasionally AB shows odd false fails like:
http://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/1/steps/Running%20Sanity%20Tests/logs/stdio
This should fix that by checking for eof instead of
polling the return code of the ssh process, because the process
might still be there.

Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
adt_installer: do not install rootfs if target is not selected

Currently, if YOCTOADT_TARGETS does not contain an architecture but the
rootfs/machine settings are uncommented, then the rootfs is installed
and adt will throw an error because is not able to find the toolchain
environment script.

This patch will:
 * not allow to install a target rootfs if the toolchain for the
   target architecture is not selected;
 * uncomment the target rootfs/machine settings for the other
   architectures since it's easier for the user to just add a new
   architecture in YOCTOADT_TARGETS and have the target rootfs
   installed;

[YOCTO #5727]

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>