image.bbclass: add function to disable SSH DNS Lookup for Qemu

This function disables the reverse DNS lookup on QEMU targets to reduce the
delay when using static IP address. By disabling DNS lookup we can save a great
deal of time during automated testing on the autobuilder (on the order of ~400
seconds per ssh tranaction). This is seen when using the testimage, there is a
delay getting logged-in from the server to target.

It's enabled for all qemu imgaes by default and can be overridden by setting
the SSH_DISABLE_DNS_LOOKUP variable.

[YOCTO #5954]

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
xorg: Fix for CVE-2013-6424

Integer underflow in the xTrapezoidValid macro in render/picture.h in X.Org
allows context-dependent attackers to cause a denial of service (crash) via
a negative bottom value.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-6424

Signed-off-by: Baogen Shang <baogen.shang@windriver.com>
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qemux86-64: re-enable paravirt guest, bring it in sync with qemux86

Seems wrong that qemux86 has this enabled and qemux86-64 doesn't.
Also this will allow people to use kvm with -cpu=host.
Right now, runqemu qemux86-64 kvm uses -cpu=kvm64 because without this
feature you can't use cpu=host on newer host kernels (>= 3.8).

This basically reverts poky e6149ec6c4c14d3a939022cdc29ac94dced836dd /
oe-core 64749308fadabb4aa7c39f360c6395827bc5eb3a
The reason of that commit (which is more than a year old) was that on
the AB running old kernels (2.6.37) we would see occasional shutdown failures.
(but if memory serves me right the fix might have been just a coincidence).

I've tested this change with by:
  - run tests on runqemu qemux86-64 (without kvm) (300 seconds)
  - run tests on runqemu qemux86-64 kvm (which uses by default cpu=kvm64) - (tests
took 20 seconds)
  - run tests on runqemu qemux86-64 kvm with cpu=host - (tests took 18 seconds)

[ YOCTO #5956 ]

Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
image/image-prelink/image-mklibs/sanity: Drop pointless EXPORT_FUNCTIONS

I'm sick of seeing people adding to EXPORT_FUNCTIONS in these classes
when they clearly have no idea what it does.

Worse, these uses of it are all broken, the naming is incorrect and
they do nothing. Lets remove them and try and preserve any remaining
part of my sanity.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
core-image-lsb: enforce pam as a needed distro feature

core-image-lsb only gave a warning:
"WARNING: Building libpam but 'pam' isn't in DISTRO_FEATURES,
PAM won't work correctly"
when the proper DISTRO was not set for it.
default choice would be DISTRO = "poky-lsb",
but not necessarily, depending on each custom distro.

This fix will enforce the proper usage of pam
as a distro feature for core-image-lsb by giving
an error instead of just a warning.

Fixes [YOCTO #6073]

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pixbufcache.bbclass: Fix setscene silent failures

Unfortunately gdk-pixbuf-query-loaders can issue errors but still return
success. We therefore check for output and error in the case any output
is issued (normal success does not issue any).

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qemu: Add addition environment space to boot loader qemu-system-mips

The qemu mips malta base board boot loader uses environment strings
with a max length of 256 bytes which is not long enough to accommodate
a long NFS path in addition to the normal kernel boot command line
arguments.

The solution is to expand the environment string length to 1024 bytes.

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Jeff Polk <jeff.polk@windriver.com>
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Qemu:Arm:versatilepb: Add memory size checking

The machine can not work with memory over 256M, so add a checking
at startup. If the memory size exceed 256M, just stop emulation then
throw out warning about memory limitation.

Signed-off-by: Jiang Lu <lu.jiang@windriver.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Jeff Polk <jeff.polk@windriver.com>
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
openssl: Fix pod2man des.pod error on Ubuntu 12.04

This is a formatting fix, '=back' is required before
'=head1' on Ubuntu 12.04.

Signed-off-by: Baogen Shang <baogen.shang@windriver.com>
Signed-off-by: Jeff Polk <jeff.polk@windriver.com>
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kmod: fix O_CLOEXEC not supported on old kernel

O_CLOEXEC is introduced from Linux 2.6.23, so old kernel doesn't have
it, we need check before use.

This patch is much more like a workaround, since it may need fcntl() use
FD_CLOEXEC to replace.

Signed-off-by: Ting Liu <b28495@freescale.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wayland-native: disable unused macro checks to fix build issue on Centos5.x

We only build wayland-native for the scanner, so disable the bits we
don't actually need. This avoid build issue on older distro such as
Centos 5.x:
| error: 'O_CLOEXEC' undeclared (first use in this function)
| error: sys/timerfd.h: No such file or directory
| error: 'CLOCK_MONOTONIC' undeclared (first use in this function)
| error: 'TFD_CLOEXEC' undeclared (first use in this function)
| error: 'SFD_CLOEXEC' undeclared (first use in this function)

Signed-off-by: Ting Liu <b28495@freescale.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libpam: fix multilib packaging issue for pam-plugins

libpam might miss ABI specific dependencies for pam-plugins-*, for RPM uses
generic names to check the packages depending on it and doesn't consider the
arch, which will lead to packaging issues in mulbilib build.

pam_plugin_hook is added because the plugin packages are dynamically
generated, so we need to manually process multilib names by add baselib to
RPROVIDES/RDEPENDS as ABI specific tag.

Signed-off-by: Ming Liu <ming.liu@windriver.com>

I worked with Ming Liu on this particular issue.  You may wonder why
this is necessary let me attempt to explain the underlying causes.

In deb/ipk on a multilib package, the package name has specific multilib
references in it.  I.e. the alternative libraries start with something
like lib32-...  This was done primarily because deb/ipk do not allow two
packages with the same name (but different architectures) to be
installed at the same time.  So the name has to be unique.

In RPM however, the names of the packages and matches with the
architectures and if they are not the same we can do these multilib
installs.  This matches the behavior of other RPM based distributions
and in many ways the tools people are used to working with RPM.  For the
most part this works fine in multilib configurations because additional
per-file dependencies are added that capture the shared library
dependencies with ABI specific information.  This unfortunately fails in
a few cases where plugins are dynamically loaded via dlopen -- such as
libpam.

One possible fix is simply to follow the deb/ipk package naming, but
this causes a design advantage of rpm.  When a package has a dependency
on 'bash', we really don't care what bash is installed, only that -a-
bash is installed.  In the deb/ipk case, the lib32- packages would end
up with a lib32-bash dependency and you could potentially end up with
two 'bash' packages being installed.

So the fix I recommended for the issue was to add the baselib path to
the internal dependencies.  Since we know that the libpam installed in
'lib' needs the modules that were compiled to also work with the 'lib'
version of libpam. While the libpam in 'lib64' need the modules to work
with the 'lib64' version of the plugins.

Existing dependencies are preserved so there is no impact in the ipk/deb
case, the RPM case is resolved as the additional dependency information
is now present for the package manager to select the package we really
want.

If anyone else has a suggestion for an alternative fix, we're interested
-- but this is the best answer we could come up with.  (If any of the
above should be added to the commit message, the YP bug, or
documentation, please let me know and I'll make sure it gets added.)

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

[YOCTO #4532]
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>