openembedded-core.git/meta/classes, branch dylan

kernel.bbclass: Complete fix for modules symlink

2015-05-29T13:49:37+00:00

The fix backported in commit aa9fc551 of oe-core does not completely fix the
issue (Yocto #4595) as intended. The modules symlink is still created in the
working directory instead of in the deploy directory. To fix this, we just need
to use an absolute path to ${DEPLOYDIR} when creating the symlink.

Signed-off-by: Paul Barker 
Signed-off-by: Richard Purdie

kernel.bbclass: Fix link for modules-${MACHINE}.tgz

2015-01-12T12:02:11+00:00

The modules-${MACHINE}.tgz should link to ${MODULE_TARBALL_BASE_NAME}.
But now it links to an invalid file ${MODULE_TARBALL_BASE_NAME}.bin.
Remove the extra .bin suffix.

[YOCTO #4595]

Signed-off-by: Yi Zhao 
Signed-off-by: Saul Wold

sstate: Fix the relative symlink replacement code

2014-12-08T09:20:38+00:00

ant reported on irc that the sstate absolute to relative symlink creation
code wasn't working in klibc. He was correct although the level of breakage is
rather surprising since it only worked for one level of symlink (usr/include) with
everything else being broken.

The reason is probably that nothing really uses absolute paths, we use relative
paths where at all possible already. Nothing in the target sysroot should use
absolute paths for a start. In this regard, the klibc-dev package is broken and
needs fixing. It will currently break when building for one machine, then switching
to another of the same TUNE_PKGARCH and installing from sstate but that is a
separate issue.

This patch fixes the symlink creation code by firstly passing in the correct
value we need (where the symlink will end up) and seccondly, actually using it.

I've also tweaked the debug message to contain appropriate information and got
right of the double "//" value the existing code created in favour of the form
'./..' which looks neater.

(From OE-Core rev: 9b05c65450526522d7358d0c0901b594de546748)

Signed-off-by: Richard Purdie

sstate: Drop 'SafeDep' code from setscene validation function

2014-03-17T23:17:03+00:00

I have a feeling this code exists from the time before we had proper
coverage of one sstate task by another task. At that time it was a
"poor" persons version of that idea, we now have much better
code internal to bitbake which handles this.

Worse, this code actually breaks certain rebuild scenarios,
e.g.:

bitbake libtool-cross
bitbake libtool-cross -c cleansstate
rm tmp -rf
bitbake libtool-cross

would fail as binutils-cross wasn't installed from sstate.

The easiest fix is to remove the obsolete/broken code.

[YOCTO #5773]

(From OE-Core master rev: ccad07f35fb7f959e24fd50d04c7d10dd5cf20d0)

Signed-off-by: Richard Purdie

cmake.bbclass: ensure CMAKE_SYSTEM_NAME is correct

2014-01-08T17:25:52+00:00

Using TARGET_OS can add the ABIEXTENSION so ensure that is is removed for the Linux
TARGET_OS, we might have other TARGET_OSes so don't hard code CMAKE_SYSTEM_NAME

[YOCTO #5145]

(From OE-Core master rev: 7d8b700242b1b32c6b6d0735b497701800f54fc4)

Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie

cmake: set system name correctly

2014-01-08T17:25:44+00:00

For unknown reasons, the cmake class is using SDK_OS as the
target system OS. This makes no sense but only shows up as a problem
when you try a different SDK OS. Fix it to use TARGET_OS which is
the correct thing to do. For the vast majority of users this will
make no difference.

(From OE-Core master rev: 57be84259f0885865c85d7bac350979430b956b5)

Signed-off-by: Richard Purdie

image-mklibs: ensure sysroot is correctly set when calling gcc

2013-12-11T19:02:38+00:00

[YOCTO #2519]

When getting gcc from sstate, it is possible to get a gcc with a bogus
sysroot configuration, as discussed in [1] or in [YOCTO #2519].

mklibs script will eventually call gcc, so we need to make sure that it
provides gcc with the right sysroot location.

[1] http://lists.openembedded.org/pipermail/openembedded-core/2013-September/084159.html

(From OE-Core master rev: 3a66dd762e493ad2cda57110be67c3b06628050a)

Signed-off-by: Nicolas Dechesne 
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie

package.bbclass: ensure license excluded files aren't packaged

2013-12-11T19:02:38+00:00

An excluded package left its files behind, which meant they could end up in
another package instead, meaning we could ship GPLv3 binaries even with GPLv3
in INCOMPATIBLE_LICENSE. Skip the files belonging to the excluded packages to
prevent this from occurring.

(From OE-Core master rev: c045bfe6b991006ac80f0e2d06a8917ae58d9262)

Signed-off-by: Christopher Larson 
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie

license.bbclass: include all licenses in the manifest

2013-12-03T16:49:24+00:00

When we don't have a generic license file for the license in question, we can
warn, but we should still include it in the manifest, otherwise the manifest
doesn't reflect reality. Failing to include a license listed in the recipe in
the manifest can't be allowed.

(From OE-Core master rev: e87232828b761d56f1ce6a27e4009d350d68209c)

Signed-off-by: Christopher Larson 
Signed-off-by: Richard Purdie

license.bbclass: fix missing of license files on ubuntu build host

2013-12-03T16:49:24+00:00

The license_create_manifest function contains bashism, this will lead
to unexpected results on ubuntu build host, as sh is linked to dash on
ubuntu. Even if COPY_LIC_MANIFEST and COPY_LIC_DIRS are enabled, the
license files will still be missing on target.

This patch fixes the above problem.

[YOCTO #5549]

(From OE-Core master rev: 4df9daee5c732c0a20dabe8515577238a1508512)

Signed-off-by: Chen Qi 
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie