Filter out any file dependencies on absolute paths and any
dependencies on Perl modules for nativesdk packages. It is assumed
that they will be provided by the native host if needed, and they mess
up the dependency handling if they are present.
(From OE-Core rev: 37f2d4df507c760ea4c12b67526db8277e5684eb)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using RPM, depends.dot may contain dependencies such as
"/bin/sh", which will confuse _toaster_load_pkgdatafile(). Ignore
them. While at it, also ignore dependencies that contain parentheses,
e.g., "libc.so.6(GLIBC_2.7)".
(From OE-Core rev: 80c117f46442ef442e34b7681ed3688789f505ac)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By using a single regular expression, the parsing of the depends.dot
file can be simplified a lot. This should also make it less
susceptible to formatting changes in that file.
(From OE-Core rev: 20684149bb659b34d3bcac8f202cb95d607567c1)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Convert incorrectly formatted dependencies such as:
"bar -> "foo" ">=" "1.2.3"
into dependencies with edge labels:
"bar -> "foo" [label=">= 1.2.3"]
* Remove rpmlib() and config() dependencies such as:
"foo" -> "rpmlib(CompressedFileNames)" [label="<= 3.0.4-1"]
and:
"base-files" -> "config(base-files)" [label="= 3.0.14-r89.49"]
* Remove the trailing semicolon that was added to each line. It fills
no purpose.
(From OE-Core rev: 99ef2f26cf498e1693a947bb44e40c31c20ec525)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes the file-rdeps test support:
* versioned dependencies, e.g., "perl (>= 5.000)", and
* package dependencies among the file dependencies, e.g., "perl".
It also ignores all "perl(...)" dependencies since it is expected that
these are generated and handled by rpm itself and there is no reason
to second guess what it is doing.
(From OE-Core rev: 6d64b110ed0c22f2bcd10cde437a13e03c15b23e)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
testdata and testdata_link may point to the same file, in particular
when IMAGE_LINK_NAME and IMAGE_NAME are equal.
Check if this is the case before creating a symlink that points to
itself and makes the next build fail.
(From OE-Core rev: f8ceec50af68650d6548738e5b5582e2b25424d7)
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use MIRRORS to provide git repo fallbacks using the https protocol,
for cases where git native protocol fetches may fail due to local
firewall rules, etc.
These rules should cover all git native repos used by recipes within
oe-core, with the exception of mtd-utils, for which there's currently
no upstream alternative to the git native protocol for anonymous
access ( see http://git.infradead.org/mtd-utils.git ).
(From OE-Core rev: fe71cf3ded7109e0fa1812475479941c89873e4e)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit abb8895d5b42a5dc171360a261a2652acd14ee7e)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we have more than one CONVERSION_CMD being used, for example
ext4.gz.sha256sum we will see errors about "metadata is not
deterministic". This is because we do not have a stable order of
intermediate files that will be removed in the generated shell command.
We fix this by calling sorted() on the set of rm_tmp_images so that we
will have a stable hash again.
Cc: Patrick Ohly <patrick.ohly@intel.com>
(From OE-Core rev: 26feb0580642ef8934206ea73cdce9e1f73d14ef)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 98a2afeb3a53bec7a72a4a9846e1dba636cc6f3d)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When chaining of compression/conversion types was added, we had a new
way to handle doing things like "ext4.bz2.sha256sum" or
"ext2.gz.u-boot". However, because the U-Boot image class isn't
included normally, it wasn't properly converted at the time. After the
support was added the "clean" argument that the .u-boot code uses no
longer functions. The fix for this inadvertently broke chaining
compression/conversion. First, correct the u-boot conversion code.
Fixes: 46bc438374de ("image.bbclass: do exact match for rootfs type")
Cc: Zhenhua Luo <zhenhua.luo@nxp.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Patrick Ohly <patrick.ohly@intel.com>
(From OE-Core rev: ad22f73519292f53d2ea6eaae99f8a919c4f2c26)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 0a7ce0b971a208956cb895ba5a869ec8c5d94703)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The package_qa_check_rdepends() in insane.bbclass has
incorrectly replace its localdata OVERRIDES value with
the package name. Fixing it by appending the package name
to the existing OVERRIDES value. This resolves RDEPENDS QA
error when setting PACKAGECONFIG using a pn- override at
local.conf.
Cherry picked from master 60d28dd72daee235150ab6605cbf953f1ea691df
[YOCTO #11374]
(From OE-Core rev: ca84390b7894adb32a89ccfbd83fbb3fb7e808fc)
Signed-off-by: Gan Yau Wai <yau.wai.gan@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* without this we cause nativesdk-linux-libc-headers to depend
on target specific KERNEL_CC (through icecc_get_tool ->
icecc_is_kernel -> KERNEL_CC -> HOST_CC_KERNEL_ARCH ->
TARGET_CC_KERNEL_ARCH -> TUNE_FEATURES(thumb) as shown by
bitbake-diffsigs:
OE qemux86@ ~/build/oe-core $ ls /OE/build/oe-core/tmp-glibc/sstate-diff/1499859497/qemu*/*sdk*/*/*do_configure.sigdata*
/OE/build/oe-core/tmp-glibc/sstate-diff/1499859497/qemuarm/x86_64-nativesdk-oesdk-linux/nativesdk-linux-libc-headers/4.10-r0.do_configure.sigdata.3a9a423878d56524e0ee8e42eba1804f
/OE/build/oe-core/tmp-glibc/sstate-diff/1499859497/qemux86/x86_64-nativesdk-oesdk-linux/nativesdk-linux-libc-headers/4.10-r0.do_configure.sigdata.401071dbaa88903ece37d35a47965ff2
OE qemux86@ ~/build/oe-core $ bitbake-diffsigs /OE/build/oe-core/tmp-glibc/sstate-diff/1499859497/qemu*/*sdk*/*/*do_configure.sigdata*
basehash changed from 39774238b66763c598153132e87a2c1a to aa2d66e770bf533e312536eb0a401c4c
Variable TARGET_CC_KERNEL_ARCH value changed from '${@bb.utils.contains('TUNE_FEATURES', 'thumb', '-mno-thumb-interwork-marm', '', d)} TUNE_FEATURES{thumb} = Set' to ''
(From OE-Core rev: b07bcfa3e4400f7763e2276f9be3dc702bb58c2e)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
KERNEL_IMAGETYPES lists all the kernel images that we want to build. in
cb17b6c2a7 (kernel.bbclass: support kernel image type of vmlinux.gz), some logic
was added to support vmlinux.gz which is not a target built by kernel
makefiles (only vmlinux). It is clear that the goal of this logic is only to
support vmlinux.gz and not others compressed format (such as Image.gz) which are
valid target for kernel makefiles.
For Image.gz we should rely on the kernel makefiles and not do the compression
in kernel class.
This patch updates the logic used to filter out non supported kernel target from
KERNEL_IMAGETYPES, and make vmlinux.gz a 'special case', instead of *.gz. If
more special cases are needed in the future, we could add them in a similar way.
This patch should be a no-op for anyone using vmlinux or vmlinux.gz, and on top
of that it is fixing the build for Image.gz which was not working until now.
(From OE-Core rev: d3a89450ae918f467a99ac1c33502fc9a5eb4162)
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit cfc0c897656fe67e81a6a5dcd936dff785529f41)
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is used by NVD database CVE's like:
https://nvd.nist.gov/vuln/detail/CVE-2017-7273
Setting this in kernel.bbclass fixes CVE reporting for all users of
the class.
(From OE-Core rev: 9b27be77980fdd51423576712dfd6f4a031c3372)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 2e3d325440a50265c73f7d2e782530a02458bc33)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This way also bbclasses can override it. For example kernel.bbclass
could set CVE_PRODUCT to linux_kernel for all users of the class
which compile Linux kernels.
(From OE-Core rev: 478b90369c48351193e2bc5e2eb2b5308d55bb2e)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 74672a7de5ada45ab8e25b89cbdea3ec33b63b7f)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
* 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Some TARGET_* flags are being exported in bitbake.conf currently, so
they are impacting all the tasks of a cross-canadian recipe even they
are not in use at all.
This can lead a lot of churn when the cross-canadian sysroot are shared
by machines while they have defined different TARGET_* flags.
Fix it by overriding with BUILDSDK_* flags.
(From OE-Core rev: 767335c92b7cc657a008722a908380a3c89c3c66)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some TARGET_* flags are being exported in bitbake.conf currently, so
they are impacting all the tasks of a nativesdk recipe even they are
not in use at all.
This can lead a lot of churn when the nativesdk sysroot are shared by
machines while they have defined different TARGET_* flags.
Fix it by overriding with BUILDSDK_* flags.
(From OE-Core rev: 85b69a5ec9ba9ea9ebdcd8ac18e1e147ddb1ff33)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some TARGET_* flags are being exported in bitbake.conf currently, so
they are impacting all the tasks of a crosssdk recipe even they are
not in use at all.
This can lead a lot of churn when the crosssdk sysroot are shared by
machines while they have defined different TARGET_* flags.
Fix it by overriding with BUILD_* flags.
(From OE-Core rev: 3facbe700a2f28a11620c4954686ed5d5e47a3d9)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some TARGET_* flags are being exported in bitbake.conf currently, so
they are impacting all the tasks of a cross recipe even they are not
in use at all.
This can lead a lot of churn when the cross sysroot are shared by
machines while they have defined different TARGET_* flags.
And sometimes it even causes "Taskhash mismatch" errors.
Fix it by overriding with BUILD_* flags.
(From OE-Core rev: 55c83cb239df5faf5e2143fffca47f2f16931cb3)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We never need these tasks as dependencies of other sstate tasks since
they're only ever needed to build artefacts so we can always skip them
and save some time/space.
(From OE-Core rev: 246df3df4b7da4b75de0745938438124c2b1d4a5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Two identical builds can end up having deploy/licenses folders
that differ. This is observed in cases where there are several
different license files of the same name in different folders,
i.e. "COPYING". In those case we have to differentiate the files
somehow and we do it via file expensions such as COPYING.0, COPYING.1.
However, which file will get which extension is presently random.
This means, for example, that COPYING.0 in one build is the same
as COPYING.1 in the other (and vice versa).
Although there is mothing wrong with this, for the sake of binary
reproducibility it is preferable to have a deterministic outcome.
(From OE-Core rev: 007ebc84979b1bc8b7520097793c7ab6d646c243)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Emit CONFFILES variable in pkgdata, or else the get_conffiles function
will return 'None' for some packages instead of the expected value. This
is especially true for optional module packages.
(From OE-Core rev: ee44dabc065912ac17f1ee5f06f12695c90b5482)
Signed-off-by: David Vincent <freesilicon@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
opkg uses empty lines as separator for next package and if an ipk file was
packaged with empty lines in DESCRIPTION opkg won't be able to handle such ipk
file, this happens at execution time.
This commit will replace empty lines in DESCRIPTION with a '.' when generating
an ipk package to avoid this issue.
[YOCTO #10677]
(From OE-Core rev: 3e678d9b6a9eaeed76ce538d7f6ecf9f423864bc)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add kernel_link_images task in kernel.bbclass instead of adding it in
linux-yocto.inc, or else the recipes inheriting kernel.bbclass might
run into implicit dependency issues.
(From OE-Core rev: 3211d43d80f69d9c200a0e4f90fd37736046aafe)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
FILESDIR is long dead and unreferenced pretty much anywhere now, drop these
sanity references too.
(From OE-Core rev: 760ab75be6b794fdcd0b1717439fcea605db9e0b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It defaults to ${INITRAMFS_IMAGE}-${MACHINE} if INITRAMFS_IMAGE is not
empty.
This allows the end users to be able to override the initramfs image
name with a customized value.
(From OE-Core rev: e788fb2b894852f71b1c545abde71b45b9f230dc)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In a addtask statement, do_strip should be strip.
(From OE-Core rev: 8413e26164644230615f4503ca9488b5b4021aeb)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This change is similar to the recently introduced
change to the distutils.bbclass fixing shebang
line in python scripts for nativesdk class builds.
v2: Rebased on top of new head.
Cc: XE-Linux <xe-linux-external@cisco.com>
(From OE-Core rev: 49772e1a1f291d1cacce27b381009dbb441c483e)
Signed-off-by: Serhii Popovych <spopovyc@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 11229de (distutils: Replacing path to native python by path
to python in the image to support python packages with
console-script setup) replaces path to python-native with path
to the python interpreter in the target image.
However on nativesdk builds ${bindir} expanded to the
${SDKPATHNATIVE}${prefix_nativesdk} making shebang line
pointing to the absolute path to env(1) in SDKPATHNATIVE
which may not be present if coreutils isn't part of nativesdk.
On the other hand commit cf63d90 (bitbake.conf: Define USRBINPATH
globally instead of individually) introduces USRBINPATH variable
which has correct value regarding build class and intended for
this use case.
v2: Rebased on top of new head.
Cc: XE-Linux <xe-linux-external@cisco.com>
(From OE-Core rev: 2a83c22a510e10b169015ce936eb51a6fc959ec1)
Signed-off-by: Serhii Popovych <spopovyc@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the new executable argument to bb.utils.which() to ensure that the symlinks
point to executable files and not for example directories with the right name
which happened to be on $PATH.
[ YOCTO #11256 ]
(From OE-Core rev: 7f40c934c3aeb1d34f95f30b281e25a17c428fce)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having arm 32/64 bit headers coexisting turns out to be tricky. Unfortunately
our wrapper works using wordsize.h and this differs on arm so we can't use it.
Therefore replicate the logic here for arm. I did look into writing our
own wordsize.h but we also need to remap kernel headers on arm and
since wordsize.h comes from libc, that doesn't work for kernel headers.
(From OE-Core rev: 141dc7136c9c62da1d30132df4b3244fe6d8898d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I suspect this was a typo and that TARGET_SYS makes more sense here. Its
also the only remaining user of MULTIMACH_HOST_SYS in OE-Core. Change it.
(From OE-Core rev: fd51900f203ae997b0f606f94ab87c12e37696c0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we get to version 12 we have a hard break as we can't convert to newer
versions. There is no point in running the old conversions on an old tmpdir
only to hit that block. Remove all the old conversions to avoid that and
make things clearer.
(From OE-Core rev: 163b27bdfe323b648929240375aaf251e8d5edf4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"bitbake -c populate_dsk_ext" must not trigger do_rm_work, because it
is impossible to declare that the additional tasks activated by "-c
populate_dsk_ext" must run before do_rm_work. When do_populate_dsk_ext
and do_rm_work are both active, the resulting race condition breaks
do_populate_dsk_ext.
The existing bitbake dependencies can't be used for that, because
"addtask populate_dsk_ext before do_rm_work" would then always execute
populate_dsk_ext also in normal builds.
do_populate_dsk_ext triggers do_rm_work indirectly through the
dependency on do_build of the SDK_TARGETs. Using the new
do_build_without_rm_work instead (when available, with do_build as
before if not) avoids the problem.
However, one has to be careful to not trigger do_rm_work in the same
build in some other way. "bitbake core-image-sato:do_populate_sdk_ext
core-image-sato:do_build" still fails, for example. Doing one after
the other works.
Fixes: [YOCTO 11042]
(From OE-Core rev: 00b1911c65fa1b21c3dedec40170998573b62178)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some classes, for example populate_sdk_ext.bbclass, must be able to
trigger a full build of a recipe without also triggering
do_rm_work. They cannot depend on do_build anymore, because that would
trigger do_rm_work.
Instead, do_build_without_rm_work can be used. It has the exact same
dependencies as do_build, minus do_rm_work and do_rm_work_all.
This may also be useful in a test build of a recipe where one wants
to preserve the work directory without having to modify configuration
settings:
bitbake foobar:do_build_without_rm_work
(From OE-Core rev: 04a7b8d6d2e86cc4dd1362c775f5e3ac1eb1d19d)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This aligns with the behavior of grub-efi and gummiboot, and is needed to fix
auto-boot of intel-corei7-64 for non-GPLv3 builds.
(From OE-Core rev: c187326afcf1e9d781c1bd0923e1362a6f50f613)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, QEMU_USE_KVM=True enabled the use of kvm only when "x86"
was in the MACHINE name. That is too limiting, because for example
intel-corei7-64 can also use kvm but it wasn't possible to enable that
without changing OE-core.
That traditional usage is still supported. In addition, QEMU_USE_KVM
can be set to a list of space-separated MACHINE names for which kvm is
to be enabled.
(From OE-Core rev: d5421dd00b9cf785fa77e77c6c739e8bd8822fa3)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Missing runtime dependencies should result in an error rather than a
warning. Indeed, if RPM is listed in PACKAGE_CLASSES, it will throw
an error rather than install packages with missing dependencies. This
functionality should be consistent across package types. This patch
ensures that an error will be thrown.
[YOCTO #10949]
(From OE-Core rev: 90bc7bfa1b27cd5ea2480463f7631f179a296b10)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In entire meta/classes/ directory, replace shell tests of the form
"if test -? ..." with POSIX tests of the form "if [ -? ...
(From OE-Core rev: 78928016f4cf38cf6751cb089200bf950d07ae93)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For aesthetic style reasons, use "grep -q" instead of ">/dev/null".
(From OE-Core rev: 39a7bfde92211b3546ff0a8e6a3e549714996b28)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When performing a file system check, the image created with mkfs will
trigger Pass 3A ('Optimizing directories') which turns the file system
into state "changed" (EXT2_FLAG_CHANGED).
This will let fsck request a reboot by setting the return code flag "2".
The result of this is that each ext-image built with oe-core will
trigger a reboot during the first time an fsck is triggered.
A common case where this might occur is when fsck detects having
a future superblock write time. This always happens when booting a
newly created ext4 rootfs with a target that does not have a recent time
set.
This patch moves the initial fsck run that performs the optimization
from the target to the host system and thus prevents the target from
performing an avoidable reboot.
(From OE-Core rev: a93d005934192402d7cceb36016b25b7d0c65547)
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Signed-off-by: Ulrich Ölmann <uol@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, if something is added to a sysroot, its hash remains unchanged,
and it continues to be buildable, it doesn't get removed from the sysroot.
This patch handles the case where something is removed from DEPENDS or
[depends].
It does introduce its own issue where something could get removed even
though some other task in parallel may have the same requirement. This
case should be extrememly rare and fixing the more common DEPENDS removal
is likely the bigger win though.
(From OE-Core rev: 06227bc5e533841ab12cde84a6ed6f8b8ddeb5cb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changed were made to the code but not reflected in vardepsexclude, fix this.
(From OE-Core rev: e59dc6985e22e7ac30b6afa81d448fbc372f5dab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The original description for this was:
"""
Since we clean out do_populate_sysroot if do_configure runs, don't
allow do_populate_sysroot_setscene functions if we're going to
run do_configure.
"""
With RSS, we don't need to clean do_populate_sysroot any more. Since
we no longer do that, this function also has no purpose any longer
and can also be removed.
(From OE-Core rev: 637c6d17b4a812379cbab64d340660092e046965)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With recipe specific sysroots its now pointless to do this, may as well
save the cpu cycles.
(From OE-Core rev: b70c8e91e6c4240e95e8b22bcc36525a5a0703f9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
BB_SETSCENE_VERIFY_FUNCTION2 replaced BB_SETSCENE_VERIFY_FUNCTION
and due to our minimum bitbake requirements there is no point in
retaining the older version any more.
(From OE-Core rev: f08d6ccda5db9fdc81d53370aea1f599718897da)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Try to avoid native recipes accidentally being dependent on
MACHINE_FEATURES. This simple change doesn't prevent MACHINE_FEATURES
set via MACHINE_FEATURES_BACKFILL sneaking through, but it's better
than nothing.
(From OE-Core rev: 96c20c9df714cdf3f0e9461ec566c4f5d3bdb5f1)
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>
Peter Kjellerstedt
Mike Looijmans
Andre McCurdy
Tom Rini
Gan Yau Wai
Martin Jansa
Nicolas Dechesne
Mikko Rapeli
Paul Eggleton
Bruce Ashfield
California Sullivan
Richard Purdie
Jonathan Liu
Joshua Lock
Chen Qi
Maxin B. John
Andreas Oberritter
Mark Hatle
brian avery
brian avery
Juro Bystricky
Aníbal Limón
Kyle Russell
Mikko Ylinen
Robert Yang
Ed Bartosh
Mylène Josserand
Jussi Kukkonen
David Reyna
Patrick Ohly
Ming Liu
David Vincent
Mariano Lopez
Ross Burton
Serhii Popovych
Christopher Larson
Alexander Kanavin
Stephano Cetola
Robert P. J. Day
Enrico Jorns