Commit Graph

5294 Commits

Author SHA1 Message Date
Paul Eggleton a19c27b807 classes/staging: change fixme debug message from note to debug
These messages were added for debugging during the recipe specific
sysroot work. They may still be useful but they don't need to be notes -
if they are they show up in recipetool / devtool output when fetching
source.

(From OE-Core rev: a0e93d5c5dcf59d1898a3db727a5ab2d75e3d20e)

(From OE-Core rev: 81246ed59215b8f62800cfb20d8b71d8e528c0ec)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit bc1a4af950a2600028d89b7dcb4ff8f409b52739)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-07-27 22:36:45 +01:00
Bruce Ashfield 912d9f531e kernel-yocto: propagate configuration errors to bbclass
As pointed out by klapperichpaul@johndeere.com, missing configuration
fragments were being picked up twice, once by the tools and once by the
bbclass. Unfortunately, the tools error message was being detected as
configs, and hence no error was reported at all.

Rather than catching the output of the tools, we can instead check the
return code and propagate the error message from the tools directly to
the user.

[YOCTO #11649]

(From OE-Core rev: 3470a3839577b99322c10f830cdaa61128ef6b16)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 960652416e2390337df6d9734375d6829ceb6420)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-07-27 22:36:45 +01:00
Paul Eggleton 00a859afd0 classes/buildhistory: fix failures collecting output signatures
It's possible for tasks to stage symlinks that point to non-existent
files; an example is ncurses-native.do_populate_sysroot. There wasn't
any error checking here so this broke the build when "task" was included
in BUILDHISTORY_FEATURES. In any case we shouldn't be following symlinks
and getting the sha256sum of the link target - we need concern ourselves
only with the target path, so check if the file is a link and sha256 the
target path instead if it is. If it's neither a regular file nor a
symlink (perhaps a pipe or a device), just skip it.

(From OE-Core rev: f60520d97f53dafe783f61eb58fe249798a1e1be)

(From OE-Core rev: 66a0d184d8f55a8da03de9fedb18d166b80b198b)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-07-27 22:36:43 +01:00
California Sullivan 7c27bf2dd8 systemd-boot.bbclass: Add configuration data to secondary EFI partition
The secondary EFI partition is used when booting in EFI mode, and
without the configuration data we don't get any boot targets.

Partial fix to [YOCTO #11503].

(From OE-Core master rev: 84aa7a00810e135fdad3f77bdb1da7d1f5fb8627)

(From OE-Core rev: 915b01258ef426392bb9052c345f952670db4450)

Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-07-07 09:19:08 +01:00
Richard Purdie f01b909a26 package_ipk: Clean up Source entry in ipk packages
There is the potential for sensitive information to leak through the urls
there and removing it brings this into the behavior of the other package
backends since filtering it is likely error prone.

Since ipks don't appear to be generated at all if we don't set this, set
the field to the recipe name used (basename only, no paths). This avoids
information leaking. We may want to drop the field if opkg can allow that
at a future point but the recipe name is a suitable identifier for now.

Reported-by: Andrej Valek <andrej.valek@siemens.com>
(From OE-Core rev: 0b5e0d072f93a958e4211a8aeb2fd8cc3c25cc21)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-06-16 10:21:02 +01:00
Jonathan Liu bebb3d36f8 image-vm: Avoid use of fold, tac and paste commands for DISK_SIGNATURE
These commands are not whitelisted by the HOSTTOOLS variable which
silently prevents the MBR disk signature from being written to the
image.

Reported-by: Michael Davis <michael.davis@essvote.com>
(From OE-Core rev: 5527af688f6ccaacd7ec24d29425d0c007d5341c)

Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-06-12 17:02:36 +01:00
Joshua Lock 607bd9ec39 kernel: predefine KBUILD_BUILD_USER and KBUILD_BUILD_HOST
By exporting KBUILD_BUILD_USER with a pre-defined value we improve the
reproducibility of the kernel and remove the requirement for whoami in the
HOSTTOOLS.
KBUILD_BUILD_HOST also helps improve the reproducibility of the kernel.

For more kernel reproducibility options see:
https://lwn.net/Articles/437864/

(From OE-Core rev: 357801a491efc067c6d4bd9a2bfa6fff460357aa)

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-06-11 23:00:58 +01:00
Chen Qi d2586b6fde cve-check.bbclass: make warning contain CVE IDs
When warning users about unpatched CVE, we'd better put CVE IDs into
the warning message, so that it would be more straight forward for the
user to know which CVEs are not patched.

So instead of:
  WARNING: gnutls-3.5.9-r0 do_cve_check: Found unpatched CVE, for more information check /path/to/workdir/cve/cve.log.
We should have:
  WARNING: gnutls-3.5.9-r0 do_cve_check: Found unpatched CVE (CVE-2017-7869), for more information check /path/to/workdir/cve/cve.log.

(From OE-Core rev: ad46069e7b58f2fba373131716f28407816fa1a6)

(From OE-Core rev: e0e1414a4574d4165a8dc5d0d9d0d5b5a660355f)

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-06-05 23:30:21 +01:00
Richard Purdie abae42362a staging: Allow BB_LIMITEDDEPS to avoid BB_TASKDEPDATA
In the limited dependency case we don't use any of the data from
BB_TASKDEPDATA. Restructure the code so this variable doesn't have
to be set. This allows the function to be called from other contexts
without creating artificial constructs. There should be no functional
change, behaviour remains unchanged.

(From OE-Core rev: 71e5243e3ebadb90b45fe418dac3eaa2c1b896bd)

(From OE-Core rev: e962e257f4c124869953d1fbb3da7dbf564f818a)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-05-18 13:17:44 +01:00
Richard Purdie 78747cc912 sstate: Ensure native/cross recipes have relocation of HOSTTOOLS_DIR
The previous change to relocate HOSTTOOLS wasn't complete as some files,
particularly in gcc stashed build directories were not being correctly
relocated. This patch addresses the issue.

(From OE-Core rev: 21dd36cc12a033b012544c5d15a6f8afd84dabc9)

(From OE-Core rev: 64c2f8acd02e0e5dca234b36a2a7097c0c16f7c2)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-05-18 13:17:44 +01:00
Maxin B. John 0fcbb4d0ec GNU_MIRROR: switch from ftp to https
Based on the same reason behind DEBIAN's switch from ftp:
https://www.debian.org/News/2017/20170425

(From OE-Core rev: ba119d836c0f4b20a39c92fa2e64abb0d5a55ad4)

Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-05-11 16:56:00 +01:00
Maxin B. John 97e194e555 DEBIAN_MIRROR: switch from ftp to http
All public-facing debian.org FTP services will be shut down on November 1, 2017
The mirrors should just be accessed using HTTP instead.

https://www.debian.org/News/2017/20170425

Fixes [YOCTO #11413]

(From OE-Core rev: c2cdc4d9155d7a3b9cba60fa9cbb448cf64c62bd)

Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-05-11 16:56:00 +01:00
Maxin B. John eb30ca2b31 useradd: remove preinst script referring to recipe sysroot
Remove recipe-specific-sysroot details from the preinst scripts
generated by useradd.bbclass.

This was added to match the default from bitbake.conf. Unlike the default
case, the dependencies used by useradd mean that a default passwd/group
file is always present. This means we don't need the native sysroot fallback.

Fixes [YOCTO #11460]

(From OE-Core rev: dfc9323c1cd7814989766be5bd1861fbaa739d2d)

Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-05-11 16:56:00 +01:00
Peter Kjellerstedt 7b56a4327b useradd.bbclass: Handle COMPONENTS_DIR when restoring state
The export of PSEUDO in useradd_sysroot() contains references to
${COMPONENTS_DIR}. These need to be handled when restoring
postinst-useradd-${PN} from the sstate cache.

(From OE-Core rev: 097875bc9ab9d60a452b01ac6825775983684d68)

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-05-11 16:56:00 +01:00
Peter Kjellerstedt 439bb8cc71 bitbake.conf: Add COMPONENTS_DIR for ${STAGING_DIR}-components
The path to where to install and find the sysroot components is used
in many places. This warrants it to get its own variable.

(From OE-Core rev: 70a84b525470f72339568409daf84845904e4cab)

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-05-11 16:55:59 +01:00
Peter Kjellerstedt 1d57ca352f sstate.bbclass, staging.bbclass: Handle HOSTTOOLS_DIR when restoring state
Paths to host tools that have been copied to ${HOSTTOOLS_DIR} may end
up in the sstate cache. They thus need to be corrected when restoring
from the sstate cache.

(From OE-Core rev: f8671aecf05a286dd2b34b07bb5fbbe0c31e26d0)

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-05-01 08:56:35 +01:00
Peter Kjellerstedt 160c4fd9ae bitbake.conf: Add HOSTTOOLS_DIR for ${TMPDIR}/hosttools
The path to where to install and find the tools copied from the host
environment is already used in a couple of places. This warrants it to
get its own variable.

(From OE-Core rev: 8164c466943ffedff399009bf5547dba4f06d6c8)

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-05-01 08:56:35 +01:00
Andreas Oberritter 470995c3c6 package_deb.bbclass: Avoid writing empty custom fields
Avoids parser errors if PACKAGE_ADD_METADATA_DEB is set to an
empty value.

(From OE-Core rev: f0959c0908dfb386d29f13fcd3e57b2b004c6c14)

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-29 11:17:23 +01:00
Andreas Oberritter a428745d15 package_deb.bbclass: Fix multi-line package descriptions
In deb control files, each line of a long description starts with
a single space. Empty lines are represented by a single space
followed by a single full stop character.

(From OE-Core rev: f66278f471c0bf9421ce2c55a56a144a0f9332bf)

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-29 11:17:23 +01:00
Andre McCurdy 33f378ee33 cmake.bbclass: use weakest ??= assignment for default OECMAKE_SOURCEPATH
Make it slightly easier to support situations where the default path
needs to be over-ridden more than once.

(From OE-Core rev: 07390e3d45cdf244079a6b91175512ebac789da0)

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-29 11:17:23 +01:00
Peter Kjellerstedt edb7672c27 cmake.bbclass: Do not use bitbake variable syntax for shell variables
Using bitbake variable syntax (i.e., ${FOO}) for shell variables is
bad practice. First of all it is confusing, but more importantly it
can lead to weird problems if someone actually defines a bitbake
variable with the same name as the shell variable.

Also use lower case for local shell variables.

(From OE-Core rev: ea6befae799f45cf93771442f242cb023dd809d1)

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-29 11:17:22 +01:00
Bruce Ashfield 929cebfb97 kernel-yocto/kern-tools: fix do_validate_branches clean stage
It was reported that do_validate_branches was failing with the following
error:

  Log data follows:
  | DEBUG: Executing shell function do_validate_branches
  | HEAD is now at fe0fb8d Merge tag 'v4.10.9' into standard/base
  | mkdir: cannot create directory .: File exists
  |
  | [ERROR] Can't find patch dir at ./patches/standard/base
  | usage: kgit s2q
  | WARNING: exit code 1 from a shell command.
  | ERROR: Function failed: do_validate_branches

This was triggered by the execution of 'kgit-s2q --clean' after forcing
the SRCREV to something other than the tip of the branch. --clean is
being run to remove any sentinel files from previous kernel builds to
ensure that the tree is in a consistent state.

There were two bugs, --clean was being executed and not exiting the
script as it was supposed to. Hence validation for applying patches
was done, and threw the error that eventually makes it to the console.

And the second bug is that since do_validate_branches actually calls
kgit-s2q --clean, the dependency on kern-tools-native needs to be on
that function (versus do_kernel_metadata which runs later).

With the tweaked kern-tool + the dependency fix, we no longer see this
error.

(From OE-Core rev: 4d5890b54cbdac01ee748759578b7b22ed8e61a2)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-29 11:17:22 +01:00
Mark Hatle d4dafce19b useradd-statids.bbclass: Add support for -P / --clear-password option
The commit 31dee7946340bf0f1e94e4e714191d3d6ca3bf6a added a new useradd and
groupadd option to specify a clear text password.  The parsing logic in the
useradd-staticid class did not understand this new option.  If the
meta-skeleton examples were run with the class enabled an error would be
generated, as an example uses the -P option.

Note, the code has a check that we do not attempt to set both a crypt and
clear text password.  It is not allowed that these two options are set
at the same time, so we prefer the crypt option if they happen to be.

(From OE-Core rev: a1715970d5c454dd24d04972ffb9cf735b5d1338)

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-29 11:17:22 +01:00
brian avery 36db8f2b78 testimage.bbclass: add additional dependency
qemu-native-helper has an additional task that needs to be run in order
for testimage to work. This task is usually run by default in a full
build but there are use cases where it might be skipped. This commit
adds the dependency explicitly.

Also, this commit adds a try/catch error message to make it clearer what
you need to do if you try to run testimage before you have built or
downloaded the image artifacts.

[YOCTO #11375]

(From OE-Core rev: 6e019537b9eb3af482e474a8cb248fe7312f4b58)

Signed-off-by: brian avery <brian.avery@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-21 08:22:09 +01:00
brian avery b2b422c190 qemuboot.bbclass: save relative paths in conf file
This saves relative paths in the qemuboot.conf file instead of absolute
paths. This is to allow the images and kernels to be relocated and still
have the testimage and runqemu work.

[YOCTO #11375]

(From OE-Core rev: 235243d7be5df57df4767e4710b846e83f0aa9fd)

Signed-off-by: brian avery <brian.avery@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-20 07:55:26 +01:00
brian avery a6275df081 rootfs-postcommands.bbclass: save relative paths
We pass the TOPDIR to do a search/replace in export2json so that we save
relative paths in the testdata.json file rather than absolute paths.
This is to allow the images and kernels to be relocated yet still allow
testimage to work.

[YOCTO #11375]

(From OE-Core rev: 7f9f1bdd714fbc6b2adc62f64bf0e4fd1d98ce05)

Signed-off-by: brian avery <brian.avery@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-20 07:55:26 +01:00
Juro Bystricky 7f0f7df8b3 kernel-arch.bbclass: conditional error message
The single purpose of "map_kernel_arch" is to set

   export ARCH = "some-arch"

The case when "some-arch" is not a valid Linux architecture results in an error.
This makes sense if the TARGET_OS is Linux, but that is not always the case.
kernel-arch is also inherited by toolchain-script, which may be used to build
toolchains for architectures not supported by Linux.

Rather than modifying toolchain-script to provide its own version of "map_arch"
this patch bypasses the error if the TARGET_OS is not linux.

(From OE-Core rev: 0b931e983b1f663d5d7dc65f1db7687334dd3ef2)

Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-20 07:55:26 +01:00
Aníbal Limón 9cb58a7f2b package_rpm.bbclass: Dosen't filter Conflicts if found in Provides
This filter was add to make compilence with debian packaging but in
package_deb.bbclass is allowed to have the same values in Conflicts and
Provides.

With this filtering errors in recipe meta-data are hidden and could end
on install two packages that conflicts [2].

Reviewing the RPM spec from Fedora doesn't have anything that denies to
use the both Conflicts and Provides with the same value [3], also in
debian manual section 7.6.2 of [4] this behaviour is allowed to force
the removal of the conflicted package and RPM is compilence with this
behaviour after remove the filtering this is seen [5].

[1]
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4b611b66743a5ec220aef34d796af63029bb5fd9
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=9349#c9
[3]
https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-advanced-packaging.html
[4] https://www.debian.org/doc/debian-policy/ch-relationships.html
[5] https://bugzilla.yoctoproject.org/show_bug.cgi?id=9349#c12

(From OE-Core rev: 2ba9dd490d69544553fc8a837fb5034a6746ab51)

Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-20 07:55:25 +01:00
Paul Eggleton 9e267ad173 classes/populate_sdk_ext: work around runqemu behaviour within the eSDK
Currently, in order to figure out variable values when run within the
eSDK, runqemu does not use the standard SDK method nor is it able to run
bitbake (since the eSDK environment isn't initialised like the normal
OE build environment). runqemu really ought to be fixed, but the quick
workaround is to set DEPLOY_DIR_IMAGE in the environment so that runqemu
can find image files.

Fixes [YOCTO #10447].

(From OE-Core rev: 1ef833b6393366a10f4bb65df89725ad65761386)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-19 10:38:37 +01:00
Kyle Russell 3b3aab0e8d cmake.bbclass: Set CMAKE_CROSSCOMPILING correctly
If CMAKE_SYSTEM_NAME is defined, CMake assumes we're cross-compiling,
which is not necessarily the case.

(From OE-Core rev: bd082c9be6191e67ea1b1bf10ce5e130a3433ab5)

Signed-off-by: Kyle Russell <bkylerussell@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-19 10:18:43 +01:00
Maxin B. John 4c6d7a20bc pixbufcache.bbclass: update postinst script name
The name of postinst scripts created by pixbufcache class
contains "useradd" in it. Remove it to avoid confusion.

As suggested by RP.

(From OE-Core rev: 2b939cd143549a3a6fc640c7c512c4ac5c246bff)

Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-19 10:18:43 +01:00
Andre McCurdy 567329b566 devupstream.bbclass: minor typo fix
(From OE-Core rev: a7761023696fbefb0d38906b0b02bf4ed211b3fb)

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-19 10:18:43 +01:00
Richard Purdie 045d01c63d populate_sdk_ext: Add do_addto_recipe_sysroot to BB_SETSCENE_ENFORCE_WHITELIST
Without this, eSDK builds are failing due to qemu-helper-native's dependency on this
task. It makes sense to allow this to execute in eSDK contexts (its a non-sstate task
intentionally).

(From OE-Core rev: 3e8ade8c0772c4492efd93824f78cb043281d235)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-14 09:47:09 +01:00
Mikko Ylinen a84a323e4d classes/populate_sdk_ext: reset TCLIBCAPPEND to get consistent TMPDIR
populate_sdk_ext sets TMPDIR to a known static value with '/tmp' directory
name and that name is hard coded in a few places (e.g., in
meta-environment-extsdk.bb that writes the eSDK environment variables).

Distros that do not reset TCLIBCAPPEND (poky does) end up getting
TMPDIR = /tmp-${TCLIBCAPPEND} via defaultsetup.conf and that breaks
the functionality in eSDK that expects everything is in /tmp.

To get TMPDIR consistent, we also need to reset TCLIBCAPPEND in
populate_sdk_ext.bbclass.

Fixes: [YOCTO #11298]

(From OE-Core rev: 9ec29153f279bb9e1dbcddc2c66e00fdbe3fd6e9)

Signed-off-by: Mikko Ylinen <mikko.ylinen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-14 09:47:08 +01:00
Robert Yang 8cedb5f3f0 binconfig.bbclass: fix typo in get_binconfig_mangle()
It should be -IOEINCDIR, not -I-IOEINCDIR.

(From OE-Core rev: 3c432e130b47461f845e1618b565f174417e1aa5)

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-14 09:47:08 +01:00
Richard Purdie b5c383074a base-passwd/useradd: Various improvements to useradd with RSS
Currently there are multiple issues with useradd:

* If base-passwd rebuilds, it wipes out recipe specific user/group additions
  to sysroots and causes errors
* If recipe A adds a user and recipe B depends on A, it can't see any of the
  users/groups A adds.

This patch changes base-passwd so it always works as a postinst script
within the sysroot and copies in the master files, then runs any
postinst-useradd-* scripts afterwards to add additional user/groups.

The postinst-useradd-* scripts are tweaked so that if /etc/passwd doesn't exist
they just exit, knowning they'll be executed later. We also add a dummy entry to
the dummy passwd file from pseudo so we can avoid this too.

There is a problem where if recipe A adds a user and recipe B depends on A but
doesn't care about users, it may not have a dependency on the useradd/groupadd
tools which would therefore not be available in B's sysroot. We therefore also
tweak postinst-useradd-* scripts so that if the tools aren't present we simply
don't add users. If you need the users, you add a dependency on the tools in the
recipe and they'll be added.

We add postinst-* to SSTATE_SCAN_FILES since almost any postinst script of this
kind is going to need relocation help.

We also ensure that the postinst-useradd script is written into the sstate
object as the current script was only being added in a recipe local way.

Thanks to Peter Kjellerstedt <pkj@axis.com> and Patrick Ohly for some pieces
of this patch.

[Yocto #11124]

(From OE-Core rev: 1b5afaf437f7a1107d4edca8eeb668b9618a5488)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-14 09:47:08 +01:00
Ed Bartosh 4273422072 sstate.bbclass: check if mirror directory is writable
Commit 51edde6537 makes a wrong assumption
that SSTATE_MIRRORS have write permissions.

A mirror is by definition outside of it's user control. In my use case
it happens I does not have permissions to update the access time of the
dereferenced symbolic-link file.

Checked if file is writable before changing its atime.

Thanks to Paulo Neves for the patch.

[YOCTO #11307]

(From OE-Core rev: b8f26c011d5ed888d85fef040bd821400d54c8fe)

Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-13 10:54:10 +01:00
Ed Bartosh ec9b108f46 qemuboot: write native sysroot of qemu-helper into qemuboot.conf
Native sysroot of qemu-helper contains all required tools
(qemu-system and tunctl atm) for runqemu to work. It's not
removed by rm_dir and should always exist. It makes sense
to write it into qemuboot.conf to make runqemu to use it
as a default directory for native tools.

This should also speed up runqemu as it doesn't need to run
to run 'bitbake qemu-helper -e' to get its native sysroot.

[YOCTO #11266]
[YOCTO #11193]

(From OE-Core rev: 0f207bfc1f7a4fd509b78d32bbe1a8d4ebea8053)

Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-13 10:54:10 +01:00
Mylène Josserand 04f3423a2a meta: classes: Add building dir to uImage creation
On the do_uboot_mkimage task from kernel-uimage.bbclass, in case
KEEPUIMAGE is different than the default "yes" value, the uboot-mkimage
command fails because the path of the created uImage does not exist.

On this task, we are under the BUILDDIR so there is no folder arch/<ARCH>/boot.
Add the ${B} (for kernel build directory) as prefix to this folder fixes the problem.

(From OE-Core rev: e5a6ee0d0655827d06a6030380277ee61a6db0ef)

Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-13 10:54:10 +01:00
Robert Yang 9dc4707035 blacklist.bbclass: fix for multilib
* Fixed:
  The netmap has been blacklisted in
  meta-networking/recipes-kernel/netmap/netmap_git.bb, but lib32-netmap still can
  be built (suppose it doesn't depend on another broken recipe netmap-modules, it
  is a little complicated, will talk below):
  $ bitbake lib32-netmap

  This is because of the old code masks on bb.event.ConfigParsed which can only
  handle global blacklist, netmap sets blacklist in the recipe, so it can't be
  handled, and lib32-netmap can be built. which was incorrect:
  blacklist_multilib_eventhandler[eventmask] = "bb.event.ConfigParsed"

  Move multilib code into multilib.bbclass can fix the problem easily:
  $ bitbake lib32-netmap
    ERROR: Nothing PROVIDES 'lib32-netmap'
    ERROR: lib32-netmap was skipped: Recipe is blacklisted: BROKEN: <foo>

* Not fixed
  Another problem is netmap-modules has also been blacklisted in the recipe, and
  the recipe inherits module.bbclass, so multilib.bbclass doesn't handle it as the
  code shows:
    # There should only be one kernel in multilib configs
    # We also skip multilib setup for module packages.
    provides = (e.data.getVar("PROVIDES") or "").split()
    if "virtual/kernel" in provides or bb.data.inherits_class('module-base', e.data):
        raise bb.parse.SkipPackage("We shouldn't have multilib variants for the kernel")

  And netmap-modules provides lib32-netmap-modules which is handled in
  multilib_global.bbclass, so bitbake lib32-netmap-modules can't show
  the blacklist message:
  $ bitbake netmap-modules
  ERROR: Nothing PROVIDES 'netmap-modules'
  ERROR: netmap-modules was skipped: Recipe is blacklisted: BROKEN: <foo>
  ERROR: netmap-modules was skipped: We shouldn't have multilib variants for the kernel

  $ bitbake lib32-netmap-modules
  ERROR: Nothing PROVIDES 'lib32-netmap-modules'. Close matches:
    netmap-modules
    netmap-modules
    lib32-fbset-modes

  Note the different messages between netmap-modules and lib32-netmap-modules.
  This is because multilib.bbclass doesn't handle the "module" recipe so
  there is no PN called lib32-netmap-modules, therefore blacklist.bbclass can't
  handle it.

  Note, there are two "netmap-modules" which needs to be fixed later.

(From OE-Core rev: c8749ed1edcbb544f6656ee5da80f2cf647c405a)

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-13 10:54:09 +01:00
Jussi Kukkonen db1f1adace native/nativesdk: Use fixed DISTRO_FEATURES
There seems to be little advantage to letting distro features affect
native builds. There is a significant disadvantage: a change to
DISTRO_FEATURES will trigger a lot of unnecessary native tasks. In a
test like this:
  $ bitbake core-image-minimal
  # append " systemd" to DISTRO_FEATURES
  $ bitbake core-image-minimal
The latter build takes 44 minutes (28%) of cpu-time less with this
patch (skipping 135 native tasks). Sadly wall clock time was not
affected as glibc remains the bottleneck.

Set native distro features to DISTRO_FEATURES_NATIVE appended with
an intersection of DISTRO_FEATURES and DISTRO_FEATURES_FILTER_NATIVE.
Current default values (baitbake.conf) are
* DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation" (as gtk-doc-native
has much less dependencies when built without it)
* DISTRO_FEATURES_NATIVE ?= "x11" (to enable native UIs even if target
does not containe them)

Do the variable setting in native_virtclass_handler() because otherwise
it could still be overridden by appends and the feature backfilling.
Shuffle the early returns so DISTRO_FEATURES gets set as long as
the packagename ends with "-native".

Add similar variables for nativesdk.

To make nativesdk work we need to enable the locale options so
nativesdk-glibc-locales can build and to avoid the init manager check
in the nativesdk case so add those fixes.

(From OE-Core rev: 731744d5538e315702be828e6f2bd556309dee07)

Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-12 15:09:58 +01:00
Robert Yang f57393b386 runqemu: do not rely on grepping images
Fixed when the image is large and not enough memory:
  grep: memory exhausted
  Aborted

[YOCTO #11073]

(From OE-Core rev: a99deb30a0138594147ae28aab016fe4b74b8959)

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-12 15:09:57 +01:00
Richard Purdie 283a9b3883 staging: Fix sysroot problem with populate_sysroot dependencies on do_fetch
Dependencies on svn:// urls were failing as the cleandirs on do_fetch was destroying
any sysroot setup by the extend_recipe_sysroot function.

Add code so that if the task do_fetch, we move the cleandirs to a separate function before
the extend_recipe_sysroot prefunc else we'd wipe out the sysroot we just created.

This allows fetcher do_populate_sysroot dependencies to work correctly again.

I did try various other approaches and a seperate function with cleandirs was the
cleanest way to add this without code duplication or too much complexity.

(From OE-Core rev: b32fbfc85b14059f0bfdeeffe2c52f8d3c20f276)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11 18:10:18 +01:00
David Reyna ba1d8e3691 toaster: fix SDK artifact capture
Use the TaskArtifacts event to scan the SDK and ESDK manifests
to cleanly collect the respective artifact files.

The previous method was broken when the SDK file deployment moved
from the do_populate_sdk[_ext] tasks to their sstate tasks. That
method is disabled (but not yet removed) in preparation for the
rest of refactor work for the parent #10283 work.

[YOCTO #10850]

(From OE-Core rev: a6ec56d372f833be50f57bcb79b6ebe78bb93be0)

Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11 18:10:18 +01:00
Paul Eggleton 3df7ee4755 classes/buildhistory: save output file signatures for sstate tasks
Save a file per task listing sha256sums for each file staged, i.e.
the output of the task. Some caveats:

1) This only covers sstate tasks since it uses SSTATEPOSTUNPACKFUNCS,
   however those are generally the most interesting in terms of output
   anyway.
2) The signature is taken before applying any relocations, so any
   relocated files will actually have different signatures, but that's
   churn that you probably won't want to see here.
3) At the moment if you run the same build twice without sstate you will
   very likely see changes in the output for certain tasks due to things
   like timestamps being present in the binary output. Fixing that is
   a general Linux ecosystem problem - see this page for our efforts to
   resolve it on our side:
     https://wiki.yoctoproject.org/wiki/Reproducible_Builds

NOTE: you need to set your BUILDHISTORY_FEATURES value to include
"task" to enable collection of these signatures as it is is disabled by
default.

(From OE-Core rev: ca5d1273432e20059ab66d721a9eb314a54e81e7)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11 18:10:18 +01:00
Paul Eggleton 54426c3a3b classes/uninative: set SSTATEPOSTUNPACKFUNCS[vardepvalueexclude] properly
Append to the value with appendVarFlag() instead of setting it outright,
so that we can also append to it in other places. Accordingly, this
varflag is pipe-separated (since we want to be able to exclude any
string fragment, in this case including the leading space), thus put a
leading pipe character to play nicely with any existing value.

(From OE-Core rev: a147838c3dfd4c53084a19b052b8d4e183293412)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11 18:10:17 +01:00
Paul Eggleton 6774995322 classes/buildhistory: write out task signatures on every build
If we want to determine what changed since the last build, one angle
from which to look at it is to check the signatures. However, if we
don't actually have the signatures from the last build we don't have
anywhere to start. Save the signatures on each build in order to give us
the starting point.

NOTE: you need to set your BUILDHISTORY_FEATURES value to include
"task" to enable collection of these signatures as it is is disabled by
default.

(From OE-Core rev: 11f68f65c46c5bc26ddeeade3021e83b3a7f895a)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11 18:10:17 +01:00
Patrick Ohly 874a46b6a7 buildhistory.bbclass: do not influence sstate of do_rootfs
Enabling or disabling buildhistory caused a rebuild of images, which
is undesirable. For example, it prevented image reuse from a main
build with buildhistory in a following oe-selftest where buildhistory
must be disabled.

The reason are the additional ROOTFS_POSTUNINSTALL_COMMAND and
ROOTFS_POSTUNINSTALL_COMMAND entries. Those need to be excluded both
via vardepvalueexclude and vardepsexclude.

(From OE-Core rev: e4c28ea05ef4514deb3d19e8e33f81d352712455)

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11 18:10:17 +01:00
Richard Purdie 0793c758b1 Revert "staging: Fix sysroot problem with populate_sysroot dependencies on do_fetch"
There seems to be an issue with the patch, revert for now.

This reverts commit cd5e0a32184d98beb8d81e6b5527166d3ca4fb3c.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-11 00:57:03 +01:00
Richard Purdie 177d4be3c1 staging: Fix sysroot problem with populate_sysroot dependencies on do_fetch
Dependencies on svn:// urls were failing as the cleandirs on do_fetch was destroying
any sysroot setup by the extend_recipe_sysroot function.

Add code so that if the task do_fetch, we move the cleandirs to the extend_recipe_sysroot
task else we'd wipe out the sysroot we just created.

This allows fetcher do_populate_sysroot dependencies to work correctly again.

(From OE-Core rev: cd5e0a32184d98beb8d81e6b5527166d3ca4fb3c)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-10 23:00:44 +01:00