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

Revert "kernel/kernel-arch: Explicitly mapping between, i386/x86_64 and x86 for kernel ARCH"

2016-05-11T02:59:39+00:00

This reverts commit a6f52930a68d8462e23486d51cdda715072dd752.

In addition to also causing the problem in [YOCTO #9579], this commit
was reverted in krogoth and master but wasn't reverted in jethro but
should be.  The original revert message was:

This reverts commit 8d310b24927d0f348fb431895f0583733db2aad0.

That commit completely breaks KBUILD_DEFCONFIG because it relies on
$ARCH to match between the target OE arch and the kernel subdirectory
containing the defconfigs. In the kernel all defconfigs for everything
x86-based (including x86_64) is stored in dir arch/x86/configs/

kernel-yocto.bbclass correctly searches for all the defconfigs inside
${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}

Commit 8d310b249 makes it search in wrong places and _only_ if you
define TARGET_ARCH = "athlon" will it search x86 which is nonsensical.

The commit further adds an if clause to hack the mungled kernel arches
back to their original values (ugh) in do_shared_workdir which is run
after do compile, but of course the build breaks before that in
do_kernel_metadata because of the KBUILD_DEFCONFIG mentioned above (so
that hack is useless).

Please fix that corner case bug in another way which does not completely
screw up the kernel arch mapping & defconfig logic. If 64bit configs are
generated in the kernel for 32bit machines because the host is asked,
then it it a bug in the kernel, it is of no use to hack around it in OE.

(From OE-Core rev: bc02a478a5d4a5de7b3943ed809d5c22711f5b1f)

Signed-off-by: Ioan-Adrian Ratiu 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 

Signed-off-by: Tom Zanussi

boot-directdisk.bbclass: remove HDDIMG before create

2016-05-09T13:37:19+00:00

Fixed when rebuild:
mkdosfs: file /path/to/hdd.image already exists

Signed-off-by: Robert Yang 
Signed-off-by: Ross Burton 
(cherry-pick from 9abcd309c098558360cde2bff65be840ead25f83)
Signed-off-by: Tim Kilbourn 
Signed-off-by: Robert Yang 
Signed-off-by: Richard Purdie

license.bbclass: fix warnings when run in unprivileged "container" env

2016-05-09T13:37:19+00:00

An unprivileged "container" environment like this[1] doesn't have root
account (uid 0) which causes tons of "Invalid argument" warnings:

  $ bitbake ...
  ...
  WARNING: Could not copy license file [src] to [dest]: [Errno 22] Invalid argument: '[src]'
  WARNING: Could not copy license file [src] to [dest]: [Errno 22] Invalid argument: '[src]'
  WARNING: Could not copy license file [src] to [dest]: [Errno 22] Invalid argument: '[src]'
  ...

Fix it by handling EINVAL similar to existing handling of EPERM (which
was added for when not running under pseudo).

[1]: The real environemnt is buildFHSUserEnv from NixOS/nixpkgs, but a
  demonstration of the issue can be done like this:

    $ touch f
    $ unshare --user --mount chown 0:0 f
    chown: changing ownership of ‘f’: Invalid argument

(From OE-Core master rev: d00b2250a6afebd7d1373c04b4006290f0cd4043)

Signed-off-by: Bjørn Forsman 
Signed-off-by: Richard Purdie 
Signed-off-by: Robert Yang 
Signed-off-by: Richard Purdie

license.bbclass: fix host contamination warnings for license files

2016-03-15T11:28:43+00:00

We get below host contamination warnings of license files for
each recipe, when we try to create a separate ${PN}-lic package (which
contains license files), by setting LICENSE_CREATE_PACKAGE equal to "1"
in local.conf.

-- snip --
WARNING: QA Issue: libcgroup: /libcgroup-lic/usr/share/licenses/libcgroup/generic_LGPLv2.1 is owned by uid 5001, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]
WARNING: QA Issue: attr: /attr-lic/usr/share/licenses/attr/libattr.c is owned by uid 5001, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]
WARNING: QA Issue: bash: /bash-lic/usr/share/licenses/bash/COPYING is owned by uid 5001, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]
-- CUT --

Since the license files from source and OE-core, are populated in a normal
shell environment rather in pseudo environment (fakeroot); the ownership of
these files will be same as host user running bitbake. During the do_package
task (which runs in pseudo environment (fakeroot)), os.link preserves the
ownership of these license files as host user instead of root user.
This causes license files to have UID same as host user id and resulting in
above warnings during do_package_qa task.

Changing ownership of license files to root user (which has UID and GID as 0)
under pseudo environment will solve above warnings, and on exiting pseudo
environment the license files will continue to be owned by host user. Perform
this manipulation within try/except statements, as tasks which are not exected
under pseudo (such as do_populate_lic) result in OSError when trying to
change ownership of license files.

(From OE-Core master rev: a411e96c3989bc9ffbd870b54cd6a7ad2e9f2c61)

Signed-off-by: Jagadeesh Krishnanjanappa 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Robert Yang

base: check for existing prefix when expanding names in PACKAGECONFIG

2016-03-11T23:14:55+00:00

When the DEPENDS are added as part of the PACKAGECONFIG logic the list of
packages are expanded so that any required nativesdk-/-native/multilib prefixes
and suffixes are added.

However the special handling of virtual/foo names doesn't check that the prefix
already exists, which breaks under nativesdk as in that situation there's an
explicit nativesdk- prefix *and* MLPREFIX is set to nativesdk-.  This results in
the same prefix being applied twice, and virtual packages such as virtual/libx11
ending up as virtual/nativesdk-nativesdk-libx11.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie

image_types_uboot: add cpio.gz.uboot to supported IMAGE_TYPES

2016-03-03T11:04:48+00:00

U-Boot needs the U-Boot header in a ramdisk image to boot it.
Add this header to the cpio.gz image, so that it can be booted
with U-Boot.

Signed-off-by: Arnold Csorvasi 
Signed-off-by: Ross Burton 

(From OE-Core master rev: 8376fa3d4ef6175b83ab7f1ec8e4e20ec14964f4)

Signed-off-by: Joshua Lock

image_types.bbclass: Rebuild when WICVARS change

2016-03-03T11:02:45+00:00

The procces to do a wic image is to save a file with
variables required by wic and then call wic using this
file. Because this is external to bitbake if the vars
change, the image won't be rebuild; an example of such
is IMAGE_BOOT_FILES.

This patch adds these variables to vardeps of do_rootfs
when a wic image is build. This will rebuild the image
if a variable needed by wic changes.

[YOCTO #8693]

Signed-off-by: Mariano Lopez 
Signed-off-by: Ross Burton 

(From OE-Core master rev: 12c54d50ed4c321dc272beb3c6cb770965c979f1)
Signed-off-by: Joshua Lock

image_types: improve wks path specification

2016-03-03T11:02:19+00:00

Hardcoding a full input path with zero flexibility goes against everything the
Yocto Project is about. Rework it to let the user specify the wks base
filename with WKS_FILE and it'll search the layers for the wks file and use
it.

Signed-off-by: Christopher Larson 
Signed-off-by: Ross Burton 

(From OE-Core master rev: 8cc7f5229f5447c2183ac319dd52c7ed737ec89b)
Signed-off-by: Joshua Lock

kernel-yocto: fix checkout bare-cloned kernel repositories

2016-02-01T16:23:27+00:00

The existing code doesn't tell regular (with .git) and bare cases and
just move the unpacked repo to the place of kernel source. But later
steps will fail on a bare-cloned repo because we can not checkout
directly in a bare cloned repo.

This change performs another clone to fix the issue.

Note: This change doesn't cover the case that S and WORKDIR are same
and the repo is bare cloned.

Signed-off-by: Jianxun Zhang 
Signed-off-by: Bruce Ashfield 
Signed-off-by: Ross Burton 
(cherry picked from commit ccfa2ee5c4f509de4c18a7054b2a66fc874d5d69)
Signed-off-by: Saul Wold

kernel/kernel-arch: Explicitly mapping between i386/x86_64 and x86 for kernel ARCH

2016-01-15T15:44:00+00:00

For a bare-bone kernel recipe which specifies 32 bit x86 target,
a 64 bit .config will be generated from do_configure task when
building 32-bit qemux86, once all of these conditions are true:

* arch of host is x86_64
* kernel source tree used in build has commit ffee0de41 which
  actually chooses i386 or x86_64 defconfig by asking host when
  ARCH is "x86" (arch/x86/Makefile)
* bare-bone kernel recipe inherits directly from kernel without
  other special treatments.

Build will fail because of the mismatched kernel architecture.

The patch sets ARCH i386 or x86_64 explicitly to configure
task to avoid this host contamination. Kernel artifact is also
changed so that it can map i386 and x64 back to arch/x86 when
needed.

Signed-off-by: Jianxun Zhang 
Signed-off-by: Richard Purdie