The linux-yocto kernel has a meta-data component which accompanies the
actual tree. That meta-data is processed to generate a series file that
controls the patching and configuration of the kernel.
patching and configuration are two distinct phases, so when working on
kernel configuration, it doesn't make sense to always have to re-run
the patching step just to update configuration data in the meta-series.
To allow a more granular set of tasks, we break the meta-data generation
into a separate task, which runs before do_patch. This allows the task
to be explicitly called when working on configuration, but otherwise
has no impact on the build.
(From OE-Core rev: 1be4c68fb876b63f19d107275b701fe1c1c121db)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If SRC_URI contains local files (file:// references) these will almost
certainly be required at some point during the build process, so we need
to actually fetch these to ${WORKDIR} as we would normally.
(From OE-Core rev: f223ad3d5b5c90055e50d1b1be69230f55e06336)
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>
Without this patch the source archiver class is not allowed to
archive the same source archive for different builds.
(From OE-Core rev: 37284185912d496a974d507bde7208d93eefc29d)
Signed-off-by: Adrian <adrian.freihofer@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
DEBUG: Executing shell function pixbufcache_sstate_postinst
g_module_open() failed for sysroots/x86_64-linux/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: libharfbuzz.so.0: cannot open shared object file: No such file or directory
(From OE-Core rev: 892c8d80e7cf36b3a45dca248969d49ce78c0cbf)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kernel-abiversion is now in STAGING_KERNEL_BUILDDIR not in S.
Fixed rpm pkg like perf: (note the None version)
perf-None-r9.qemux86.rpm
(From OE-Core rev: 85bb679f22b2f5fb308016e62356bd1d6ba455a0)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Binaries linked with gold may contain a RUNPATH instead of an RPATH.
Update chrpath.bbclass process_file_linux() to handle both cases.
(From OE-Core rev: 46ceb4d035e4f49e6b4a3a83bf604944d2b991c1)
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>
Fixed:
ERROR: Build of do_populate_lic failed
ERROR: Traceback (most recent call last):
File "bitbake/lib/bb/build.py", line 497, in exec_task
return _exec_task(fn, task, d, quieterr)
File "bitbake/lib/bb/build.py", line 437, in _exec_task
exec_func(func, localdata)
File "bitbake/lib/bb/build.py", line 212, in exec_func
exec_func_python(func, d, runfile, cwd=adir)
File "/home/nxadm/nx/ala-blade44.1/builds-2015-03-09-163005/qemuppc_world_oe_bp/bitbake/lib/bb/build.py", line 237, in exec_func_python
os.chdir(cwd)
OSError: [Errno 2] No such file or directory: 'bitbake_build/tmp/work/ppc7400-wrs-linux/taglib/1.9.1-r0/build'
When running setscene, the cwd is $B which maybe removed by
autotools.bbclass or cmake.bbclass when rebuild.
(From OE-Core rev: b3262af11094f93c9588f2e3edc70a5058491e6d)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some people like to have the devshell start in ${B} instead of ${S}, so allow
this to be overridden.
(From OE-Core rev: 217af639d13258429949b14c67110650288cba7a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Started to run into this error on ubuntu 15.04
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "run_buildstats(e)", line 18, in run_buildstats(e=<bb.event.BuildStarted object at 0x7f93341c1b50>)
File "buildstats.bbclass", line 17, in set_device(e=<bb.event.BuildStarted object at 0x7f93341c1b50>)
SystemError: ../Objects/longobject.c:998: bad argument to internal function
ERROR: Command execution failed: Traceback (most recent call last):
File "/home/ubuntu/work/bleeding/openembedded-core/bitbake/lib/bb/command.py", line 102, in runAsyncCommand
commandmethod(self.cmds_async, self, options)
File "/home/ubuntu/work/bleeding/openembedded-core/bitbake/lib/bb/command.py", line 303, in buildTargets
command.cooker.buildTargets(pkgs_to_build, task)
File "/home/ubuntu/work/bleeding/openembedded-core/bitbake/lib/bb/cooker.py", line 1336, in buildTargets
bb.event.fire(bb.event.BuildStarted(buildname, fulltargetlist), self.data)
File "/home/ubuntu/work/bleeding/openembedded-core/bitbake/lib/bb/event.py", line 163, in fire
fire_class_handlers(event, d)
File "/home/ubuntu/work/bleeding/openembedded-core/bitbake/lib/bb/event.py", line 102, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/home/ubuntu/work/bleeding/openembedded-core/bitbake/lib/bb/event.py", line 76, in execute_handler
ret = handler(event)
File "run_buildstats(e)", line 18, in run_buildstats
File "buildstats.bbclass", line 17, in set_device
SystemError: ../Objects/longobject.c:998: bad argument to internal function
similar to here
http://pycuda.2962900.n2.nabble.com/bad-argument-to-internal-function-td4063274.html
If it is right fix .. Dont know
Change-Id: I84f3a4043ad5246e080dfd7e2f066e5292d4af91
(From OE-Core rev: 5f85a7549d119177c5d39f965b949e957e07867e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Appending to PACKAGEFUNCS results in the font packages missing the
postinst/postrm scripts and the fontconfig cache not being generated
in /var/cache/fontconfig when creating images or installing font
packages. This is because the package data has already been emitted
by emit_pkgdata in PACKAGEFUNCS. Prepend to PACKAGEFUNCS to ensure
add_fontcache_postinsts is executed before emit_pkgdata.
[YOCTO #7410]
(From OE-Core rev: f0e3db4eaacc32423934ce09b91bc619dc5dbd21)
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The file ownership of the cache files in /var/cache/fontconfig needs to
be set to root:root otherwise it inherits the user and group id of the
build user.
[YOCTO #7411]
(From OE-Core rev: 23393c6685860d0b1c459874d35395360d0b6d3c)
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For now, if we enable 'multilib' and execute `bitbake uninative-tarball
-c populate_sdk', the command would fail, complaining nativesdk-glibc not
found in package feed.
The problem is that PKGDATA_DIR is not set correctly for nativesdk packages
when multilib is enabled.
For now, we have:
meta/conf/bitbake.conf:PKGDATA_DIR = "${STAGING_DIR_HOST}/pkgdata"
The above is overriden by the following is multilib is enabled.
meta/conf/multilib.conf:PKGDATA_DIR = "${STAGING_DIR}/${MACHINE}/pkgdata"
This is correct for normal packages. However, for nativesdk packages, this
is not correctly. This is because nativesdk.bbclass set STAGING_DIR_HOST as
follows.
meta/classes/nativesdk.bbclass:STAGING_DIR_HOST = "${STAGING_DIR}/${MULTIMACH_HOST_SYS}"
The above overrides the value in multilib.conf.
That's why we need to also set PKGDATA_DIR explicitly in nativesdk.bbclass.
(From OE-Core rev: 2f99ee5725ffc173bf32c0b707aa90adbc4eed95)
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>
Previously, files with absolute paths in LIC_FILES_CHKSUM such as
"file://${COMMON_LICENSE_DIR}/foo" would not result in a qa failure
when the license file changed.
To fix this problem, add any files with absolute paths from
LIC_FILES_CHKSUM to the file-checksums varflag, so that changes in the
license file are detected and cause the qa task for licenses to run.
[Yocto #6450]
(From OE-Core rev: 5df681259ae078c9d04d426fb5971eaa79d35ba5)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new send-error-report will prompt for review of items and the server is
now specified by using the -s argument.
(From OE-Core rev: c195d70f35ea522854dcdd53aeae60eec6b7ad7e)
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
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>
