We don't require that a yocto custom kernel + defconfig have a full BSP
description (but of course it would be better if they did). Since this
isn't a requirement, we shouldn't alarm users by generating a BSP
description warning.
To implement this, we add a bsp audit level flag (like the one that
exists for kconfig audits), and only set it to activate in the versioned
linux-yocto recipes.
[YOCTO: #7370]
(From OE-Core rev: d2fb7fff291b83700d487be093223c1533d915ce)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
os.walk() returns symlinks to directories in the "dirs" lists, but then never
enters them by default. As a result, the old code applied neither the
directory handling (because that is active once a directory gets entered) nor
the file handling, and thus never packaged such symlinks.
The fix is simple: find such special directory entries and move them to the
"files" list. However, one has to be careful about the undefined behavior of
modifying a list while iterating over it.
This fix was required for packaging a modified base-files that created
symlinks into /usr for /sbin /lib and /sbin.
(From OE-Core rev: 9c4ab427b6acbc3f708860adace65393562227a7)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This bbclass will create an SDK with a copy of bitbake and the metadata
and sstate for the target specified for the task. The idea is to let
"system" developers both work on applications and then test adding them
to an image without having to switch between workspaces or having to
download separate items.
Rather than running bitbake directly however, the primary way of running
builds within the extensible SDK is to use the "devtool" command. The
rest of the build system is fixed via locked shared state signatures,
and thus only the recipes you have added get built.
(From OE-Core rev: bf81d6bb7f6df5405b8f2148e2a22e0030c12757)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the buildsystem is copied into the sdk and its toolchain is to
be used, then the relocation provided in toolchain-shar-template.sh
isn't needed and will actually fail.
So break the relocation aspect out and essentially make it another
SDK_POST_INSTALL_COMMAND script.
(From OE-Core rev: 9721378688a05cd8d8443c6ee4be823e5c0688f6)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To add some flexibility to setting up the paths for the toolchain,
add some parameters. This initial use will be in order to point at
the buildsystem toolchain copied in by copy_buildsystem.py.
(From OE-Core rev: 62930ea37cfd5ba787ee85bc8dab23c20a775253)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you create a build directory with poky, or set DISTRO to "poky" and
run bitbake, you'll get a bblayers.conf file with LCONF_VERSION set to
6. If you then set DISTRO to any other value where the new distro config
doesn't pull in poky's config, e.g. "nodistro", you would then get a
bblayers.conf version error which didn't immediately make sense. (The
layer versions have been out-of-step ever since meta-yocto-bsp was
split out of meta-yocto several years ago).
This is just painful and we'd rather users didn't have to deal with
it. Obviously it isn't an OE-Core problem per se, but a simple way to
resolve it for everyone is to bump OE-Core's version to 6 with an
automatic no-op upgrade. Also ensure that multiple upgrade functions
(such as the poky one) have a chance to execute by not breaking out of
the loop as we were before.
Fixes [YOCTO #6139].
(From OE-Core rev: 2fdeee2fad69445b0d97148826c7b027820be63a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Add do_shared_workdir which was added recently
* Add do_fetch and do_unpack to this list, because at the moment if you
enable externalsrc through a bbappend the += in this class wipes out
the original value from externalsrc (which is set with ?=)
(From OE-Core rev: 5717e3b60731d2cb9394c13bff049a467c3aeec1)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make sure there's no chance of anyone forgetting they have a recipe set
up for externalsrc; otherwise you could get confused about what is going
on. (With our default logging setup we can't make it a note because the
UI doesn't forward those; otherwise I would have used bb.note().)
(From OE-Core rev: 7b73473bc9d19331a103cf4958059d3ceb84b486)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Here we set SRC_URI to blank, however doing so means that the function
that is called when you expand the default value of SRCPV
(i.e. bb.fetch2.get_srcrev()) will fail, so any recipe that references
SRCPV in PV couldn't previously be used with externalsrc.
(At some point we may fix the function to work in the externalsrc case,
but then we would also need to ensure that ${B} did not change as a
result of PV changing any time the HEAD revision changes in the external
source tree, or you'll lose any intermediate build artifacts.)
(From OE-Core rev: 26f8060c3475ec988194b2163e422ba4e776fd8b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kernel.bbclass adds ${S} do do_clean[cleandirs], but this means if you
run bitbake -c clean <kernelrecipe> then your external source tree will
be trashed, which could be a disaster. For safety, remove ${S} from
cleandirs for every task. We also have to do the same for ${B} in the
case where EXTERNALSRC_BUILD is set to the same value as EXTERNALSRC.
(From OE-Core rev: b5071fb2667b8751885d38ca62fa36c870177cd5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 0b891265716c414ade29d587fc1a3c4ea7beadbe.
U-Boot does support AArch64, this however was only added to newer
versions of U-Boot and at the time of this original commit the U-Boot in
OE-Core did not support the 'arm64' architecture. OE-Core now has a
newer version of U-Boot for the mkimage recipe and thus supports the
'arm64' architecture.
(From OE-Core rev: fd8158134f3d7a7c795c818cc50eb2858a6cae06)
Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The meta data (in tree or out of tree) that describes a BSP, its patches
and configuration is not always available when a new/default or manually
configured machine is built.
When this happens, the tools generate a skeleton BSP and use a
architecture defconfig for the build. If this is by design, the build
is typically sane and everything works fine. If an existing BSP
description was expected, chances are that the resulting kernel will not
be correct.
To avoid surprising the user when a default/skeleton BSP is used for the
build, we can make it obvious to the user by emitting a warning like
the following:
WARNING: [kernel]: An auto generated BSP description was used, this normally indicates a misconfiguration.
Check that your machine (myqemux86-64) has an associated kernel description.
[YOCTO: #3383]
(From OE-Core rev: f4a460afc4e2676cbf1daaa1d6723da9e6146526)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After a linux-yocto style kernel is configured, a kernel configuration
audit is executed to detect common errors or issues with the config.
This output used to be visible, but was made less obvious to not alarm
users unnecessarily (since some configuration issues are acceptable).
There are some classes of configuration issue that are worth being
visible, and that is specified configuration values that do not make the
final .config. These dropped options can result in any number of runtime
failures, so flagging them at build time makes sense.
The visibility of auditing is controlled by KCONF_AUDIT_LEVEL:
0: no reporting
1: report options that are specified, but not in the final config
2: report options that are not hardware related, but set by a BSP
The default level is 1, with level 2 and above being for BSP development
only.
If these conditions are detected, warnings will be generated as follows:
WARNING: [kernel config]: specified values did not make it into the
kernel's final configuration:
Value requested for CONFIG_SND_PCSP not in final ".config"
Requested value: "CONFIG_SND_PCSP=y"
Actual value set: ""
or
WARNING: [kernel config]: BSP specified non-hw configuration:
CONFIG_BLOCK
CONFIG_CFG80211_WEXT
CONFIG_CORDIC
CONFIG_CRC8
CONFIG_EFIVAR_FS
CONFIG_EFI_PARTITION
CONFIG_NET
CONFIG_NETDEVICES
CONFIG_PARTITION_ADVANCED
CONFIG_WEXT_CORE
CONFIG_WEXT_PROC
CONFIG_WIRELESS
At this point thse are only a warnings, since there needs to be time for
layers and configuration fragments to be validated against this new
check.
[YOCTO: #6943]
(From OE-Core rev: ad4d59495194b37bc510e9891bd14c0a2ac30dba)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow globs in CONFFILES.
This patch changes the way of CONFFILES handling. After this change,
the CONFFILES can take the same form as FILES. That means, we don't
have to list a bunch of files for CONFFILES. It will just be expanded
like the FILES variable.
We don't assume default value for CONFFILES in OE. But distro vendors could
provide a default value for CONFFILES in their distro configuration file
like below.
CONFFILES = "${sysconfdir}"
In this way, files under /etc are treated as configuration files by
default. Of course, setting CONFFILES in recipes take precedence over
the CONFFILES. For example, if the recipe author decides that package A
should only treat files under ${sysconfdir}/default/ as config files,
he/she can write like this.
CONFFILES_A = "${sysconfdir}/default"
[YOCTO #5200]
(From OE-Core rev: 0d446ef0e5bbca7058eec7259e34f2a1637dfab1)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* add quotes around pkged_lic so that it works correctly with spaces
* fixes following error:
run.license_create_manifest.50601: 193: [: GPLv2: unexpected operator
(From OE-Core rev: 2bb8b2abb689d91b7b7e28e6bd528747bde94dd2)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If /etc/login.defs is treated as a configuration file, then we would meet
errors at do_rootfs time telling us that useradd/groupadd cannot execute
correctly.
This is because the dpkg handles config file specially, the login.defs
is temporarily renamed as login.defs.dpkg-new.
How ubuntu deals the user/group adding problem? They do it at postinst of the
package. And, the postinst script of a package would possibly do `chown' of
its files or directories.
The above strategy is not suitable for OE. Because we do chown in do_install
and add user/group in preinst scripts of the packages.
That's why we need this patch so that do_rootfs don't fail.
(From OE-Core rev: d98e5ec575f542b3afaabd96b07ae9a21e1c22f4)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use '-f' ('--force') option so that while removing packages using deb,
we don't fail because of the following error:
update-rc.d: $initd/$bn exists during rc.d purge (use -f to force)
Using '-f' option would make this a warning but continue to execute.
update-rc.d: $initd/$bn exists during rc.d purge (continuing)
We need this option because dpkg package backend have special handling for
configuration files. And if files under /etc/init.d are treated as configuration
files, we will have errors.
(From OE-Core rev: ebb2d557bbf410d98040cdaabbddd7e3ee0a9709)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similar to commit 4569d74 for create_wrapper function, this commit fixes
hardcoded absolute build paths in create_cmdline_wrapper.
Otherwise we end up with incorrect paths in users of this function. For
example the 'file' wrapper in current released toolchain:
exec -a
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-arm/build/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-file/5.18-r0/image//opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/bin/file
`dirname $realpath`/file.real --magic-file
/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/share/misc/magic.mgc
"$@"
(From OE-Core rev: 49ab89eb9f83388e99069a4b53bdc4cba22bb6f3)
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a check to the SDK so that it only runs on systems with kernel versions
it supports.
[YOCTO #6856]
(From OE-Core rev: b4caa8085aa15674162ff5135b13409998db9510)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Defines ${BLUEZ} to be the provider of bluez services as specified by
DISTRO_FEATURES.
Example recipe fragment:
inherit bluetooth
PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}
PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4"
PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"
[YOCTO #5031]
(From OE-Core rev: 045484283530bced19bb1d3aea229c8f138f510a)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The midori is built well now.
(From OE-Core rev: 445135f4fdd5878a0660029d0876aec51f971e20)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the new items to the validitems list, this is fully tested, initial testing
had been done with a local change that did not make the original commit request
[YOCTO #7308]
(From OE-Core rev: 6e48bc5fbd834f19bdcac17007d27a750cc5f331)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Use argparse instead of optparse for standardised help output, options
and a much cleaner code structure
* Look up pkgdata directory automatically so the user doesn't have to
specify it
* Use standard logging
NOTE: this does mean a slight change in syntax - if you do want to
specify the pkgdata directory (usually only necessary if you're calling
it from within the build process) you need to use the parameter -p (or
--pkgdata-dir) and specify this before the command, not after it.
Examples:
oe-pkgdata-util find-path /sbin/mke2fs
oe-pkgdata-util lookup-recipe libelf1
oe-pkgdata-util read-value PKGSIZE libc6
oe-pkgdata-util -p /home/user/oe/build/tmp/sysroots/qemux86-64/pkgdata read-value PKGSIZE libc6
(From OE-Core rev: 04dc571ac7c26f0dcf1a1fcd466482e22519998d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The qmake_base class generates internal qt.conf for build with hardcoded
qt4 target paths. This is ok for qt4-x11 as this is the default
$QT_DIR_NAME, but it is wrong for qt4-embedded, because qtopia is its
default directory.
(From OE-Core rev: f4b8c0faa1cebda2a2742f8e4d622dcd024428e9)
Signed-off-by: Tomas Novotny <tomas.novotny@tbs-biometrics.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a siteinfo enabled tasks re-executes at the wrong moment whilst something else is
in do_configure, the _config files can be removed which upsets autoconf and
causes build failures.
Use the same approach as we do for dealing with the aclocal files. We already
parse the manifests so look out any *_config files and if so, copy them, then
reference the copy from siteinfo instead. This has the advantage of also being
more deterministic.
[YOCTO #7101]
(From OE-Core rev: c8b7aad133c3e3319345d50f85a91cbd5116f842)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Checks in FILES and pkg_* variables, solves common mistake of
using ${D} instead of $D and warns the user accordingly.
[YOCTO #6642]
(From OE-Core rev: e3ea62b370f69d2435e76f6e444f5d3a3b25eb17)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
BUILDNAME is set by cooker as a string of current time. Letting do_rootfs
task depend on this variable gets us no benefit. Besides, letting do_rootfs
task depend on this variable will cause us trouble when executing
`bitbake -S none core-image-minimal'. With current code, this command
gives us error complaining about the different bashhash of do_rootfs task.
(From OE-Core rev: eb6305d03723527830976c3a4ce2342a0e09eefc)
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>
Split the debug-tweaks into a more fine tunable set of IMAGE_FEATURES
which activate the component functions.
Clean-up image-core and image bbclass by having the ROOTFS_POSTPROCESS_COMMANDs
in in one place for the debug-tweaks related functions
[YOCTO #5344]
(From OE-Core rev: e52d8281eb98dbade2d82451fa9788285121437e)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Strictly speaking not all of these characters are operators, so reword
the message to describe them as separators. Also use the standard
"recipename: message" format.
(From OE-Core rev: 9e5da3e83f2a5d43620e07a31728b7427329d8f4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The ">" should be ">>".
We had got something like the following in pcap-config:
echo '--should-not-have-used-/usr/bin/pcap-config'
exit 1
(Lacks of #!/bin/sh)
(From OE-Core rev: d4adf9ac1b8318d4eb3f1c8dd82bbf04c6908eb5)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds support to build multiple U-Boot configs for a machine; this
is useful when we have support for different media boots which require
different U-Boot configuration (e.g: eMMC and NAND).
Below there's an usage example:
,----[ i.MX6Q SABRE AUTO based example ]
| UBOOT_CONFIG ??= "sd eimnor nand spinor"
| UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard"
| UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config"
| UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs"
| UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config"
`----
(From OE-Core rev: be997c70e4dec101786978b3ab5e49a1be87a85d)
Signed-off-by: Chunrong Guo <B40290@freescale.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All non-arch-specific and non-distro-specific configuration is now kept in the
main 'opkg' recipe and package.
(From OE-Core rev: e8879cd1ec8914815c7a78f1d9b296b0e2b30fcf)
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The unknown-configure-option check is generally useful and should be enabled by
default.
(From OE-Core rev: 2f1909a6a78dec943800a0e8a39f890c007165b7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a recipe (say, wayland) has DEPENDS=wayland-native and BBCLASSEXTEND=native,
when built as wayland-native it has DEPENDS=wayland-native which results in a
circular dependency.
Typically this is resolved by having explicit DEPENDS_class-native statements
but as this is duplication which can lead to inconsistent dependencies,
automatically remove the circular dependency.
(From OE-Core rev: 3e9392c0965166462e0993d46f4cc2fb1832f1e5)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows an image to skip the creation of kernel depmod
data. It is useful for creating an image that will run as a
container image inside a host with no knowledge of the parent's
kernel.
(From OE-Core rev: ca641aedff5f6bd155796ead02cb2eb871f8c17a)
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since the rewrite of the image construction code in python a few
releases ago, we remove a couple of packages from the image as one of
the final steps when constructing the image (notably update-rc.d and
run-postinsts). However, because of the order of operations, these
packages are still listed both in the buildhistory
installed_package*.txt files and in the manifest file created next to
the image, which is wrong.
There were two possible solutions to this: (1) change the order such
that the uninstallation occurs before calling ROOTFS_POSTPROCESS_COMMAND
or (2) add another hook variable in such that we can have the
package list collection code run at the right time. Because it's
currently possible (but very much not recommended) to install additional
packages within ROOTFS_POSTPROCESS_COMMAND, which may have postinstall
scripts and thus require the packages we would otherwise uninstall if we
were to take option 1, option 2 is really the least likely to cause
problems. Therefore, add ROOTFS_POSTUNINSTALL_COMMAND and make the image
and buildhistory classes use it.
Fixes [YOCTO #6479].
(From OE-Core rev: b198a189228648057c3be7d068598f50841b3bf9)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you add an item to EXTRA_IMAGE_FEATURES in your local.conf that is
not supported by image.bbclass itself (such as "tools-sdk" which is
implemented in core-image.bbclass), it can be somewhat annoying to have
the parse fall over if you have a recipe that inherits image.bbclass
only. Change the error from bb.fatal to skip the recipe instead so that
you only see the error when attempting to build the recipe, plus add a
bit of logic to report if the feature is coming in via
EXTRA_IMAGE_FEATURES.
Fixes [YOCTO #5023].
(From OE-Core rev: cbe9d2f748125aa2dffc829570d46f8dbc1781a4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the daisy (1.6) timeframe, when we rewrote the image construction in
Python, we neglected to reimplement the support for the little used and
undocumented variable MACHINE_POSTPROCESS_COMMAND, and apparently nobody
noticed. We have a better method for implementing machine-specific image
formats that is in wider use (i.e. add a custom class which implements
the new image type, add the class to IMAGE_CLASSES and the type to
IMAGE_FSTYPES), and we now also have wic. Thus it makes more sense to
just call this variable unsupported now and drop the sole remaining
reference to it.
(From OE-Core rev: 46fef857d6c4ac25d89b71b542b019d0ed068c19)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a log data cannot be decoded to utf-8 or read then handle this
gracefully. This can happen if a log file contains binary or something
goes wrong with the file open process.
(From OE-Core rev: 787ffc5e12f1639aa5e0917bb23deced53a0478e)
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was added back in the depths of history (around 2006 in OE-Classic)
when apparently the host sed couldn't always be relied upon. We now call
the host sed all over the place without this dependency and don't have
any problems. On the other hand, having it around can lead to races
where we're calling sed in one task and staging it to the sysroot in
another, the result being nasty failures compiling binutils for example.
Since it isn't needed, let's just drop it completely.
Fixes [YOCTO #7264].
(From OE-Core rev: 863a3966e1a200e7a15fbdbb8e04dce6e3f6c1a2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The newer btrfs-utils needs an empty file to build the filesystem in, so
create an empty file and use it for the mkfs to build the fs in.
[YOCTO #6804]
(From OE-Core rev: 224c24d8a8ea6230ed56ea61cdb86e78c5ec4311)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using populate_sysroot for this data was a nice idea but flawed as it
doesn't work in multilib builds. Instead we can use PKGDATA_DIR since
this is consistent over multilib builds. It also turns out to be
slightly neater code too. Hopefully this resolves the problem once and
for all.
(From OE-Core rev: 6cccae3ca54c1177a1d91d23c3e151d74e735ee9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need the depmod data so that the kernel depmod command works successfully
at rootfs time. The fact this was working inconsistently is now highlighted
after the command was made to error out. A simple test case is:
bitbake virtual/kernel image
bitbake vrituak/kernel -c clean
bitbake image -c rootfs -f
We fix it by adding the missing dependency, the data is in PKGDATA_DIR and
hence we use packagedata.
(From OE-Core rev: 41f0f86ec0a3e0b6f6c9bb4ef71a4215c00bf66c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* it's not complete, but recipes depending on virtual/libx11 are easiest
to spot, I've long list of PNBLACKLIST for all recipes which cannot
be built in distro without x11 in DISTRO_FEATURES
(From OE-Core rev: fda535d5b5239b091c79e957f68a45d4eab0ab5d)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
--047d7b3a7fac0eebee050cb47483
Content-Type: text/plain; charset="UTF-8"
After we check the existence of 'machine_branch' with 'git show-ref'
the following if statement should change the 'machine_branch'
to the default (i.e. master) if the 'git show-ref' has returned an
exit code that is not 0, not the other way around.
Signed-off-by: Theodor Gherzan <theodor@resin.io>
(From OE-Core rev: cc95da21914d08bfbf1936830985f824e8813904)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The purpose of binconfig-disabled is to manipulate config scripts such that
using them causes errors. But that only works when the modified config script
really gets installed in the sysroot. That is not the case with the staging
code in binconfig.bbclass.
Only patched config files get staged. For that reason it seemed more
appropriate to change binconfig-disabled instead of binconfig.
The reason for the change was the observation that the swig recipe needs
pcre-config installed on the host system. Staging pcre-config removes that
host dependency. swig did not actually end up *using* the pcre-config from the
host, because later during do_compile the patched configure.ac is used to
re-generate configure.
(From OE-Core rev: 822df6d23c9c24e131c38fda9f0012c47ad7af46)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Returning a non-zero exit code is not enough to cause errors when configure
scripts call the patched config scripts: for example, swig's configure script
uses PCRE_LIBS=`$PCRE_CONFIG --libs` and does not abort on errors. Using empty
output may then succeed, for example when the required library is available
indirectly.
Returning some nonsense command line arguments covers such cases, because
using them will definitely lead to errors during compilation. The faked
arguments were chosen such that these errors can be linked back to the root
cause.
(From OE-Core rev: d1ff61a16a3fcfdd7cf882bc89fb1d164cb1603a)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For cpio images, do_rootfs() can operate on a dirty '${WORKDIR}/cpio_append'
directory which contains e.g. files from previous builds. This can cause
unwanted files in the image or can break the build.
E.g. when there is a cpio_append/init -> /sbin/init symlink symlink, the
'ln -sf' can fail due to SELinux restrictions:
| $ ls -la cpio_append/init
| lrwxrwxrwx. 1 ensc ensc 10 22. Jan 16:26 cpio_append/init -> /sbin/init
|
| $ strace ln -sf /sbin/init cpio_append/init
| ...
| stat("cpio_append/init", 0x7fffbb9ca310) = -1 EACCES (Permission denied)
| exit_group(1) = ?
Patch cleans up 'cpio_append' before executing the 'do_rootfs' task by
adding it to 'cleandirs'. An alternative implementation (which avoids
creation of this empty dir for non-cpio images) might remove it within
IMAGE_CMD_cpio, but this might break builds where people rely on the
existence of this directory (e.g. to add local files).
(From OE-Core rev: 4db3cc2360289c062fa0df4678f2f2ef990f0c1a)
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When /init is a dangling symlink or a symlink to a file which can not be
stated on the build system (e.g. due to SELinux restrictions), the '[ !
-e .../init ]' test will succeed which causes the manual creation of
/init.
E.g. here:
| $ ls -la cpio_append/init
| lrwxrwxrwx. 1 ensc ensc 10 22. Jan 16:26 cpio_append/init -> /sbin/init
|
| $ strace /bin/test -e cpio_append/init
| stat("cpio_append/init", 0x7fff374a9db0) = -1 EACCES (Permission denied)
| exit_group(1) = ?
To test for the existence of a file, both '-L' and '-e' checks must be
executed and to prevent SELinux noise, the '-L' should happen before
'-e'.
(From OE-Core rev: 2aa5d2880ee3578f4965f245addd365fb7b1c1ca)
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bruce Ashfield
Patrick Ohly
Randy Witt
Paul Eggleton
Nathan Rossi
Chen Qi
Martin Jansa
Javier Viguera
Richard Purdie
Peter A. Bigot
Robert Yang
Saul Wold
Tomas Novotny
Alejandro Hernandez
Chunrong Guo
Paul Barker
Ross Burton
Dan McGregor
Michael Wood
Theodor Gherzan
Enrico Scholz