The Cooker requires a copy of the environment mapping, modify
bitbake-layers to take one and pass it to the cooker.
(Bitbake rev: f5653e557b68a27e99a2a6a5c5a31d0ba0b56bcb)
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we have a pristine copy of the variables available at launch time
we can use them when looking to inherit the OS's environment.
(Bitbake rev: 21c21fcc5871e81d8d497b6baed605cdd74c4571)
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently oe.utils.contains(X, "A", true, false) will return true for substring matches,
e.g. if X = "ABC". This is not what most users expect from the function.
In the common OE use of this function there is the case of "touchscreen" and "screen" being
used as independent variables. Whilst it could be argued there isn't a problem in that
specific case (touchscreens are usually on screens), there is no substring usage of this
function is OE-Core so this patch changes the behaviour to match only full strings.
It also fixes a bug where duplicate entries would confuse multiple matches, e.g.
contains(X, ["A", "B"], ...) would match X = "A A" which is clearly wrong.
(From OE-Core rev: 5c09cbe3bf456e968fc853827698eb18b62e8348)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently bb.utils.contains(X, "A", true, false) will return true for substring matches,
e.g. if X = "ABC". This is not what most users expect from the function.
In the common OE use of this function there is the case of "touchscreen" and "screen" being
used as independent variables. Whilst it could be argued there isn't a problem in that
specific case (touchscreens are usually on screens), there is no substring usage of this
function is OE-Core so this patch changes the behaviour to match only full strings.
It also fixes a bug where duplicate entries would confuse multiple matches, e.g.
contains(X, ["A", "B"], ...) would match X = "A A" which is clearly wrong.
(Bitbake rev: 3d8647b68a8e66c7b240ed5fed7406e1b78fabf6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These changes revolve around the idea of tune features. These are represented by
'flag' strings that are included in the TUNE_FEATURES variable.
Any string included in TUNE_FEATURES should also add a TUNEVALID[<name>] entry so
we can know which flags are available in TUNE_FEATURES and have documentation about
what the flags do. We will add sanity code to error if flags are listed in
TUNE_FEATURES but are not documented in TUNEVALID.
A given tune configuration will want to define one or more predetermined sets of
_FEATURE flag lists. These are defined in the form TUNE_FEATURES_tune-<name>.
For defined tune configuation, <name> should be added to the AVAILTUNE list so that
we can determine what tune configurations are available. Flags cannot be used in this
case as with TUNEVALID since its useful to be able to build up tune lists from other
TUNE_FEATURES_tune-yyy options.
A given tune configuration may also define PACKAGE_EXTRA_ARCHS_tune-<name> and
BASE_LIB_tune-<name> to control the multilib location. All options can be overridden
by the distro or local user configuration.
(From OE-Core rev: 5f9d56bd64997b93ed7e46c117851002a0556654)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch removes the variables BASE_PACKAGE_ARCH, BASEPKG_HOST_SYS,
BASEPKG_TARGET_SYS and also removes the immediate assignments in
several core classes as these are no longer required.
This should make it clearer what some of the core variables do and
simplfy some overly complex and confusing class code.
(From OE-Core rev: d5521be2dcbaf213c140b0d12a4176380874426b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The perl-dynloader.patch can't support lib64 lib32, libx32, etc.
Relax the regular expression to fix this issue.
(From OE-Core rev: 7ebc7a5cb30e13217dc297994a6d9656b52bacba)
Signed-off-by: Mei Lei <lei.mei@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Invoking runqemu outside of the build directory for an
in-tree setup results in an empty TMPDIR because bitbake -e
cannot be run to find it.
A symptom of this problem is running runqemu and getting the
following error:
Error: Unable to find tunctl binary in <directory>
Catch this case and report the error to the user.
This fixes [YOCTO #1278]
(From OE-Core rev: ab5544ac801a976b56468ade0f5d2e95c11feb87)
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1250]
This added function will install a private install-catalog binary so that shared state
can find the binary as there is not a guarantee.
(From OE-Core rev: b3e68f112cff5f15b5245582eee7e087acbad2fa)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1250]
This added function will install a private install-catalog binary so that shared state
can find the binary as there is not a guarantee.
(From OE-Core rev: b4eef2e1bed0536325342ca884ee0905b7e79ada)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1250]
This added function will install a private install-catalog binary so that shared state
can find the binary as there is not a guarantee.
(From OE-Core rev: 188ac8c8fe7a004c576190c42d0f33d00ea88c60)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The base gcc package is missing liblto_plugin.so. If we try a simple
hello world compile we get something like:
root@p5020-ds:~# gcc hello.c
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.
We need to include liblto_plugin.so in the base gcc package and not
gcc-dev.
(From OE-Core rev: 282326a188467edf6caef21b07a7e51288674245)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create a data store in the cooker containing the values of the environment
from when BitBake is launched such that child processes can replicate
(and/or use values from) the host environment, rather than the cleaned up
environment that the main BitBake process uses.
(Bitbake rev: 54c7206165c0e7cfe5f7b243c80461baf5e7dfb1)
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_EOF is only needed when using the Python cmd class in line-oriented
mode - we are just sending single commands to it.
(Bitbake rev: 0cbf5dcaf9f67522bd58d868aa01f28e846dfc19)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you run "bitbake-layers help commandname" it now provides some useful
help text.
(Bitbake rev: 1548edcd18a78bab74cde39167169f11ba3c4d58)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Don't always parse on initialisation - instead check for errors and then
parse when we know we need to. Avoids keeping the user waiting.
(Bitbake rev: 86adaca6ce959ad5e908c394625bc9880f3c0216)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Default server is process, adjust comments and messages accordingly.
(Bitbake rev: 8ba4d0e98401cdb808f727703913ad8ba87f8e71)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Too many people are using -b because they think it is the normal way of
specifying a target to be built, and then get confused when the build
fails due to a missing dependency; so show a warning about dependencies
not being handled when this option is used.
(Bitbake rev: c470f3f36aef24c46d9722593422286340be296b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The -b option doesn't handle dependencies so note this in the help.
(Bitbake rev: b133b2e2dd5bcde705397eb38fa20a5c4da6e3b3)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The preferences UI to set the image output type only supported setting a
single value whereas it's common practice, particularly for those making
use of the ADT, to set multiple values. This is also the default in Poky.
This reworked preferences UI dynamically generates check boxes for each
available image type and sets an appropriate string representing all image
types when checkboxes are toggled.
Includes fixes for [YOCTO #1273]
(Bitbake rev: f7f68847dd165f2ad0f39011db4ebfef3ae73f42)
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't have a good handle on a sane cap value so just set it to an
arbitrary, but reasonably high, number. Once we have some more numbers on
values for number of threads and make parallelism we can integrate the
algorithm into the GUI.
Addresses [YOCTO #1266]
(Bitbake rev: 31274e78eab502f5eb9f6079897644b535d31dd1)
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a user added the same layer more than once the underlying bblayers.conf
file would not have multiple entries but the UI would show an entry for
the layer for each time it was added. This patch changes the Configurator
to return None values if the layer wasn't added to bblayers.conf and the
LayerEditor to only update the UI if non-None values are returned.
Fixes [YOCTO #1275]
(Bitbake rev: 9c59baa4da3c863ebc412a56ffd8dbd7a8ffeb60)
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When resetting and clearing all selections the searched for term is no
longer the selected row in the packages list, clear the search entry to
prevent cognitive disconnect.
(Bitbake rev: 4f86f5763ecf7f3a9673a9b18e96042e9387699b)
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This ensures we understand e.g. "virtual:multilib:lib64:pn" for multilib.
(Bitbake rev: 0b9dee799cfe2229ec62c257dda36bd6c15d34a9)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For multilib this produces variants of e.g. "multilib:lib64" instead of
just "lib64"; however we set BBEXTENDVARIANT to "lib64" and the latter
will be used when composing filenames for multilib.
(Bitbake rev: de7a2b91512bb3ab058f5eb5cd188acd2b8a2220)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we're updating the tune file format, it makes sense to abstract
the compiler tune arguments at this point too. This means that should
these need to be overridden at any point, the original values can
still be obtained in a similar manner to the other TUNE* variables.
Whilst this isn't strictly necessary for any current need, its likely
good practise to standardise this behaviour.
(From OE-Core rev: 3a3c69a1bc3cf0b6f6a3b13d86c12ed21798d48e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is currently consideradble confusion over how the tune files operate
and how these interact with the rest of the build system. This update/overhaul
changes things so the tune files are primarily resonsible for setting:
TUNE_ARCH - What was formerly set as TARGET_ARCH and is the value that
represents the architecture we're targetting.
TUNE_PKGARCH - The value that represents the tune confuration that this set
of tune parameters results in.
This allows the significant improvement that the core can now always determine
the target architecture value, even when TARGET_ARCH needs to be reset to
something different and likewise, there is one package architecture variable
the core can reference allowing simplification of the BASE_PACKAGE_ARCH, PACKAGE_ARCH
and FEED_ARCH variables.
(From OE-Core rev: a10de4cf8b424ee95c8e283e75d486be5b3b8eac)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the ability to dynamically change the library directory from "lib" to
other values. This allows the tune files to specifiy altnerative ABIs
which can be dynamically enabled by the multilib BBCLASSEXTEND code.
A variety of approaches have been attempted with this, the immediate
expansions in cross.bbclass being problematic as they are they are expanded
before the bbclass extend event hander runs. This approach ensures the
${baselib} variable is retained in the expressions resolving that complication.
Derived from some ideas from Mark Hatle.
(From OE-Core rev: aeea22da699b276a97ca1a17e3c53176c9afd9de)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The MPC8315E has a e300c3 core in it with 'classic' or normal PPC
floating point.
'SPE' floating point is what exists on the e500v2 core.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This function is needed by some of the early .conf setup we need
to improve the machine/tune files in Openembedded. We need to add
it here since the location in oe.utils can't be accessed until after
base.bbclass parses which is too late for our needs.
(Bitbake rev: abc67ed6921c98ed581f101ec1acc589fd9ce7e9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The plugin got installed into the wrong dir leading to:
gdm-session-worker[515]: PAM unable to dlopen(/lib/security/pam_gnome_keyring.so): /lib/security/pam_gnome_keyring.so: cannot open shared object file: No such file or directory
(From OE-Core rev: f31ae697803bad73052066f7b39317f8a01695d4)
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Pulled common options that are needed for powerpc64-linux to build
out of powerpc32-linux and put them into powerpc-linux.
(From OE-Core rev: d5a42bb0382243d12388a0e0b18461c58d12c60e)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use ac_cv_sizeof_* from eglibc as starting point for powerpc64-linux
site info. We will refactor common bits that are needed out of
powerpc32-linux based on build issues.
(From OE-Core rev: 0f094d208b4a6ea21fb69a3e770f5bf742bf2155)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we have a unique powerpc32-linux config, we share powerpc-linux
between ppc32 & ppc64.
(From OE-Core rev: 405a9a90f756c215e7454a4231179bc49c77ad1d)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
powerpc-common was really Linux PPC32 specific. So move all the options
in it to powerpc32-linux and we can refactor out common bits shared
between into powerpc-linux and powerpc-common.
(From OE-Core rev: 6ba64ae1030c879021f0ee0789bee4f8d3c135c0)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If try to build for an ppc64 target openssl will fail to build since
the configure script didn't know how to handle a 'linux-powerpc64' target.
(From OE-Core rev: 9c98851951ba79a5e1a6a7daa2a3552dcf3adf86)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Joshua Lock
Richard Purdie
Mei Lei
Scott Garman
Saul Wold
Kumar Gala
Dexuan Cui
Paul Eggleton
Koen Kooi