classes/package_rpm: remove unsed outdir variable

Not only outdir had the wrong value, it wasn't used actually used in that function.

Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
lib/oeqa/runtime: smart: limit channel add to useful ones

Don't add inappropiate channels on the target.
This happens when building two different machines in the
same dir and then running the tests for each machine.

Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ia32-base: only depend on GL if opengl DISTRO_FEATURE enabled

As Mesa refuses to compile if the "opengl" DISTRO_FEATURE isn't enabled,
mesa-driver-i9xx and the GLX X module have to be conditional in the ia32 machine
defintion too.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
xf86-video-vesa: change depends to refect reality

This recipe appears to have been a copy-and-paste from -intel, because it has
dependencies and configure options that xf86-video-vesa just doesn't have, such
as virtual/libgl and XVMC.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
xf86-video-intel: disable DRI2 tests if no DRI2 is available

Somehow this slipped past the initial testing and can cause build errors in
non-GL distros.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bluez4/5: Add EXCLUDE_FROM_WORLD = 1

We can't build both recipes in the world build as there is a collision of package name
and PR values. Specificly the libasound-module-bluez which is the same in both goes
backwards from r5 (bluez4) -> r0 (bluez5) and the subpackage_metadata check fails:

ERROR: Recipe lib32-bluez5 is trying to change PR from 'r0' to 'r5'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find the right workdir.

[YOCTO #5165]

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
xf86-video-vmware: respect opengl DISTRO_FEATURE

Conditionalise the GL dependencies on the opengl DISTRO_FEATURE so this driver
can build without the opengl feature active, as the configure script will
enable/disable the GL sub-driver depending on the presence of these libraries.

This is an interim patch to fix the autobuilder, a more complete patch heading
upstream to make the GL sub-driver deterministic will follow.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
populate_sdk_rpm: Ensure empty strings aren't passed to attemponly rpm code

If empty strings are passed to the rpm attemptonly code, it breaks. This
ensures we don't do that.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
x11vnc: add dependencies for xrandr/xfixes/xdamage/xtst

Inspired by a patch by Martin Jansa but with these libraries required, as a VNC
server without them is suboptimal.  Don't add an option for Xinerama as our X
server always disables it.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
clutter: fix compilation when building without X11 backend

If Clutter is building the Wayland backend but not the X11 backend, the Cogl
support doesn't get enabled so the Wayland backend (which uses it) fails to
compile.

Backport a fix from upstream to fix this situation.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
weston: as weston-launch depends on PAM, control it with a PACKAGECONFIG

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
populate_sdk_rpm: Only remove trailing whitespace, not all whitespace

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libnewt-python: Don't write a whiptail package

The whiptail package is written by the libnewt recipe so for the python version
we need to ensure its not in PACKAGES.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sstate.bbclass: fix parallel building issue

sstate_package creates hardlink from sysroot to SSTATE_BUILDDIR, then
sstate_create_package will store SSTATE_BUILDDIR into a archive file by
tar, but once other packages install the same file into sysroot, the
creating the archive file will fail with below error:

    DEBUG: Executing shell function sstate_create_package
    tar: x86_64-linux/usr/share/aclocal/xorg-macros.m4: file changed as we read it

This kind of error is harmless, use --ignore-failed-read to ignore it.
The error in tar occurs when the timestamp of the file changes and this
can happen when the number of symlinks change. The file will be included
in the archive.

[YOCTO #5122]

Signed-off-by: Roy.Li <rongqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bb-matrix: Clean before, rather than after, building

This makes sure the the first build starts from a clean state. Otherwise
one could have the first build affected by any leftover state from
a previous build.

This also leaves a working state behind after the final build.

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake.conf: Stop providing ${P} and ${PF} by default

For a long time we've provided PN-PV and PN-PV-PR by tweaking PROVIDES. This looks
nice at first glance however it turns out to be a bit problematic. Taking make as an
example where there are two versions, 3.81 and 3.82, what should "bitbake make-3.81" do?

Currently it builds make-3.81 and make-3.82 and breaks in interesting ways. Is that
a bitbake bug? Well, it certainly shouldn't try and run the build. Why is it building
3.82 though? Its due to finding a dependency on "make-dev" and then trying to figure
out what provides it? The answer is "make" and the default version of "make" is 3.82.

So arguably, finding "make-3.81" should infer PREFERRED_VERSION_make = "3.81". Doing
so resolved the above problem since now "make" resolves to "make-3.81".

So what about if we have Recipe A:
DEPENDS = "make-3.81"
and Recipe B:
DEPENDS = "make-3.82"

That is clearly an error, easy. So finally what about if we have Recipe A:
DEPENDS = "make-3.81"
and Recipe B:
DEPENDS = "make"

The first recipe infers the PREFERRED_VERSION_make = "3.81" and then forces that
version on everything else. Is that desired? Probably not in most cases, at least not
silently.

As mitigation, we could print a WARNING about this happening. The final part of the problem
is that we can ony figure this out within bitbake itself. That means we'd have to teach bitbake
about the PN-PV format of PROVIDES which is breaking the separation between bitbake and the
metadata. We can't win :(.

Nobody that I know of is using or relying on this functionality so perhaps we should
just remove it instead which is what this patch does. Opinions?

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bb-matrix-plot: Use interpolation for sparse data

If not every combination of BB_NUMBER_THREADS and PARALLEL_MAKE have
been tested by bb-matrix.sh, e.g., by using BB_RANGE="04 08 10 12 16"
and PM_RANGE="04 08 10 12 16", then the graph that gnuplot generates by
default looks very jagged due to the missing data points. By using
splines to interpolate the missing data the graph looks a lot better.

This should not change graphs where all data points are available in any
way, only improve sparse graphs.

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
perf: source should be ready after do_unpack

In perf.bb:

S = "${STAGING_KERNEL_DIR}"

So the source should be ready after the do_unpack, and we need this:

do_unpack[depends] += "virtual/kernel:do_populate_sysroot"

Otherwise, maybe no source after do_unpack.

[YOCTO #5168]

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
icu-native: do_install: Segmentation fault

There was a "Segmentation fault" error when build icu-native when the
TMPDIR is in a deep directory (for example, when len(readlink -f $TMPDIR
== 410)), use LARGE_BUFFER_MAX_SIZE for cmd rather than
SMALL_BUFFER_MAX_SIZE would fix the problem, this should be a misplay
because other cmd uses LARGE_BUFFER_MAX_SIZE.

[YOCTO #5171]

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake.conf: include machine name in DEPLOY_DIR_IMAGE

This allows a clean seperation between image outputs from different
machines, and makes it possible to have convenience symlinks to make
the output ready to deploy.

This did require some surgery in runqemu; if explicit paths to the image
and kernel are not supplied then DEPLOY_DIR_IMAGE needs to be determined
from bitbake or set in the environment. However the script does try to
avoid requiring it unless it really is needed. Corresponding changes
were made in the automated testing code as well.

Based on an RFC patch by Koen Kooi <koen@dominion.thruhere.net>

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>