| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Move classes to classes-global or classes-recipe as appropriate to take
advantage of new bitbake functionality to check class scope/usage.
(From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
As stated in our top level license files, the license is MIT unless
otherwise stated. Add SPDX identifers accordingly. Replace older
license statementa with the standardised syntax. Also drop "All
Rights Reserved" expression as it isn't used now, doesn't mean anything
and is confusing.
(From OE-Core rev: 081a391fe09a21265881e39a2a496e4e10b4f80b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
Where there isn't a copyright statement, add one to make it explicit.
Also drop editor config lines where they were present.
(From OE-Core rev: 880c1ea3edc8edef974e65b2d424fc36809ea034)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
A previous fix for zero length bb_unihashes.dat files wasn't complete
as there is a second copy of the unihashes file made. Change this second
call site to match the first to fully fix the zero length file issue.
(From OE-Core rev: 962bd78af1acc86b3d900dce9081ed310616e0fa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a race were the bb_unihashes.dat file may end up zero sized due to
concurrent builds. Use recently added API within bitbake to copy the file
safely. Also use the opportunity to remove hardcoded filepaths internal to
bitbake from OE-Core.
Bump the minimum bitbake version to match the API being used.
(From OE-Core rev: 106a7e07057e4681e6fb06dfe9e28d2e183d667d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
Update internal variable names to improve the terms used.
(From OE-Core rev: f408068e5d7998ae165f3002e51bc54b380b8099)
Signed-off-by: Saul Wold <saul.wold@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
| |
(From OE-Core rev: aa52af4518604b5bf13f3c5e885113bf868d6c81)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
After other variables were renamed in bitbake, update OE-Core to match.
(From OE-Core rev: 91812ba5a34598e03ad860745707c7cba1ae5d91)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
After the change to bitbake, update the references in OE-Core to match the updates.
(From OE-Core rev: 193affb9f28b0116c3fd619834f145326fee08c5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lnr is a script in oe-core that creates relative symlinks, with the same
behaviour as `ln --relative --symlink`. It was added back in 2014[1] as
not all of the supported host distributions at the time shipped
coreutils 8.16, the first release with --relative.
However the oldest coreutils release in the supported distributions is
now 8.22 in CentOS 7, so lnr can be deprecated and users switched to ln.
[1] 6ae3b85eaffd1b0b6914422e8de7c1230723157d
(From OE-Core rev: 1ca455a98de4c713f58df0a537d4c982d256cd68)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
| |
(From OE-Core rev: f5a90df08631117cd66bec68cb1851db96822bb8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current way TOOLCHAIN_HOST_TASK is handled within eSDK builds is
causing much confusion, even to people who should understand the code.
For a normal SDK, some layers append to TOOLCHAIN_HOST_TASK unconditionally
which is fine, until the eSDK tries to override the variable to it's own
values. It does not support or use packages installed using this variable
and would use native recipes instead, it is a very different approach.
In the referenced bug, binaries are added but not relocated leading to
confusing errors.
To fix this, add a new variables for the eSDK TOOLCHAIN_HOST_TASK
to be explict and force the eSDK code to use this instead. The setVar
in non-parsing context will clear out any appends resolving the current
issues. The patch also gets rid of some dubious task override use.
[YCOTO #14047]
(From OE-Core rev: 30912ba084aa8600156edddbe4f2db0b85e869d0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
The automated conversion of OE-Core to use the new override sytax isn't
perfect. This patches some mis-converted lines and some lines which were missed
by the automation.
(From OE-Core rev: 4e9a06b64b43131b731fb59a0305f78a98e27fbd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running a build such as:
bitbake mc:my_config:core-image-minimal -c populate_sdk-ext
will result in an error like:
ERROR: Task base-files.do_fetch attempted to execute unexpectedly
Task .../poky/build-mc/tmp-my_config-glibc/work/qemuarm64-poky-linux/core-image-minimal/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-core/base-files/base-files_3.0.14.bb:do_packagedata, unihash ec5ba0e6b31561daba005fb49c5239c8e46913465b51166b5905f3e5ffcf2741, taskhash ec5ba0e6b31561daba005fb49c5239c8e46913465b51166b5905f3e5ffcf2741
Task .../poky/build-mc/tmp-my_config-glibc/work/qemuarm64-poky-linux/core-image-minimal/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-core/base-files/base-files_3.0.14.bb:do_package_write_rpm, unihash 1c7d7509c2ff6dcf11009fbec444726826214795d60474ec8d3262d89c40a955, taskhash 1c7d7509c2ff6dcf11009fbec444726826214795d60474ec8d3262d89c40a955
Task .../poky/build-mc/tmp-my_config-glibc/work/qemuarm64-poky-linux/core-image-minimal/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-core/base-files/base-files_3.0.14.bb:do_populate_sysroot, unihash 9cc3672f4fa62491f545b15cf617a64cd77d15a2cfd432b57d4b936bc415f40d, taskhash 9cc3672f4fa62491f545b15cf617a64cd77d15a2cfd432b57d4b936bc415f40d
Task .../poky/build-mc/tmp-my_config-glibc/work/qemuarm64-poky-linux/core-image-minimal/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-core/base-files/base-files_3.0.14.bb:do_package_qa, unihash 8ada5f62092c971df8dda1d71c728e42994e1dcf2bbdab419de43867d77b64cc, taskhash 8ada5f62092c971df8dda1d71c728e42994e1dcf2bbdab419de43867d77b64cc
Task .../poky/build-mc/tmp-my_config-glibc/work/qemuarm64-poky-linux/core-image-minimal/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_qa, unihash 16656a339389e407a5fdca5d64983af845288f3b3cc5582398e5247efb393257, taskhash 16656a339389e407a5fdca5d64983af845288f3b3cc5582398e5247efb393257
Task .../poky/build-mc/tmp-my_config-glibc/work/qemuarm64-poky-linux/core-image-minimal/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-core/images/core-image-minimal.bb:do_image_complete, unihash ef88c74a9f4ae4d252c421eb4e399773aa50cea7c51ffbeed9011e5198a16abb, taskhash ef88c74a9f4ae4d252c421eb4e399773aa50cea7c51ffbeed9011e5198a16abb
This is usually due to missing setscene tasks. Those missing in this build were: {'.../poky/build-mc/tmp-my_config-glibc/work/qemuarm64-poky-linux/core-image-minimal/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-core/base-files/base-files_3.0.14.bb:do_package_qa',
Instead of letting the system error, we simply tell the user this is not supported.
As long as the eSDK is constructed based on the primary library, it works fine.
(From OE-Core rev: b359c60071585fa323124fc6febe652fe0128b52)
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As the generated local.conf includes BBMULTICONFIG, the referenced files
in conf/multiconfig also need to be copied. Otherwise with
BBMULTICONFIG="abc" for instance, building the esdk fails with:
ERROR: ParseError at tmp/build-glibc/work/qemux86_64-oe-linux/core-image-ssh/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/openembedded-core/meta/conf/bitbake.conf:767: Could not include required file conf/multiconfig/abc.conf
(From OE-Core rev: 8bc339b83a45becc0c7edf016fcce187152669e3)
Signed-off-by: Justin Bronder <jsbronder@cold-front.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Incremental build in Docker fails with:
OSError: [Errno 18] Invalid cross-device link
when source and destination are on different overlay filesystems.
Rather than adding fallback code to every call site, use a new wrapper
in bitbake which detects this case and falls back to shutil.move
which is slower but will handtle the overlay docker filesystems correctly.
[YOCTO #14301]
(From OE-Core rev: 656a65b2b84e7d529b89cf5de7eb838f902d84a2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the classes/populate_sdk_ext.bbclass the system already copies a number
of configurations, such as the hash equivalency data. However, the PR
service was being handled.
The new code works by checking if PRSERV_HOST is defined, if it is, use
the existing export functions to write out a conf/prserv.inc file into
the eSDK. On eSDK install, if a conf/prserv.inc file is present we then
import this file into the system.
This mechanism will work if the PRSERV_HOST is local or remote, as it pulls
the necessary data from the server and then imports it to a local database
on eSDK installation.
Note: the conf/prserv.inc file is not deleted at this time. It was left
for possible debugging purposes, but removing it is something we could decide
to do in the future.
(From OE-Core rev: e207dabdfaa07cd5ebba1cd7dd58610f7185c7e2)
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since pyc cache files are really system specific, no real reason to copy or
generate them during the eSDK build process. Also generating them has the
possibility of re-using inodes that pseudo may have been tracking, leading
a build failure.
(From OE-Core rev: ce8eba263647ae63a722122e28f26af46ae083a0)
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As we delete the .git/ directory, it's impossible to get METADATA_REVISION
inside eSDK. Because of this, we meet the following warning when installing eSDK.
WARNING: The base-files:do_install sig is computed to be 16b9d96148d45de183cc94667aae016ec7d102d48255456381e718cd4bbd0aa0, \
but the sig is locked to 6eb0dcaed504282becee94662481d79264db920dee1f7deda18230133fff8f36 in SIGGEN_LOCKEDSIGS_t-qemux86-64
So we record METADATA_REVISION in eSDK generation time to fix this problem.
(From OE-Core rev: ff2ad51b801fd62e2abbc573ba2c9ee8fdc7e012)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
templateconf.cfg
The current implementation will always pick an existing templateconf.cfg if
present else it will use the one from OE. A user might not always want to pick
an existing tempalteconf.cfg even if its present. Introduce
SDK_CUSTOM_TEMPLATECONF variable to provide an option for the user to specify if he
wants to use an existing custom templateconf.cfg or not
If SDK_CUSTOM_TEMPLATECONF=='1' then enable custom templateconf.cfg. By default
SDK_CUSTOM_TEMPLATECONF is set to '0'
(From OE-Core rev: d0f863a24d05bddeb21e181fb01fa0051c79d7d8)
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add ESDK_MANIFEST_EXCLUDES to enable excluding items in sdk-conf-manifest.
By default, files under conf/ are all added to sdk-conf-manifest, as the
manifest file is set to 'conf/*'.
However, there are situations where some configuration files under conf/
directory are not intended to be added to sdk-conf-manifest, thus adding
ESDK_MANIFEST_EXCLUDES to enable users to do this.
This variable takes the form of glob matching.
e.g.
ESDK_MANIFEST_EXCLUDES = "conf/autogen*"
This would exclude all files under conf/ starting with 'autogen' from
sdk-conf-manifest.
(From OE-Core rev: 2d71e427b530ec4ea5524efa951b6a87f21b8b22)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Some distros may not have local.conf, and use auto.conf or site.conf
alone to describe distro config metadata, therefore make code robust
to not fail eSDK builds for such setups
(From OE-Core rev: 6379f951ba92b2b86a55de5fc267bacf8c6095d2)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
buildtools is built as a nativesdk which needs to use OECORE_NATIVE_SYSROOT
for its own purposes and can reset it. Save and restore the value
within the eSDK so the two don't clash.
(From OE-Core rev: 513f4006bf563620ee063ba6d0e9b3f27334642e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
We should be using python3 here, it was missed in the conversion. Spotted on
autobuilder tests failing on systems with python missing.
(From OE-Core rev: db07b09196022078346aadd565760240b7da6a71)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Do not always override templateconf.cfg content. Add option to use
already existing file.
(From OE-Core rev: e524e49ef22fd69882d5d2d01cd84db790e9cb88)
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
We no longer expect a "python" binary in PATH so update the eSDK's
expectations to match. This was the only failure on autobuilder test
systems with python missing.
(From OE-Core rev: 946ce21b10dcad506edcaadb4e4242c049e4c316)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the sanity_info file has moved from the conf directory to the
cache directory, there is no longer any need to clean it away
explicitly in clean_esdk_builddir() since the whole cache directory is
already cleaned away anyway.
(From OE-Core rev: 40c30990e1be72130819c040fe471e2bdc0c6e7d)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This stack trace is horrible and obscurs the real failure message, avoid that.
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:copy_buildsystem(d)
0003:
File: 'build/meta/classes/populate_sdk_ext.bbclass', lineno: 446, function: copy_buildsystem
0442: sdk_ext_type = d.getVar('SDK_EXT_TYPE')
0443: if (sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative) and not sdk_include_nativesdk:
0444: # Create the filtered task list used to generate the sstate cache shipped with the SDK
0445: tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
*** 0446: create_filtered_tasklist(d, baseoutpath, tasklistfn, conf_initpath)
0447: else:
0448: tasklistfn = None
0449:
0450: if os.path.exists(builddir + '/cache/bb_unihashes.dat'):
File: 'build/meta/classes/populate_sdk_ext.bbclass', lineno: 182, function: create_filtered_tasklist
0178: # Clean out residue of running bitbake, which check_sstate_task_list()
0179: # will effectively do
0180: clean_esdk_builddir(d, sdkbasepath)
0181: finally:
*** 0182: os.replace(sdkbasepath + '/conf/local.conf.bak', sdkbasepath + '/conf/local.conf')
0183:
0184:python copy_buildsystem () {
0185: import re
0186: import shutil
Exception: FileNotFoundError: [Errno 2] No such file or directory: 'tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/sdk-ext/image//opt/poky/3.0/conf/local.conf.bak' -> 'tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/sdk-ext/image//opt/poky/3.0/conf/local.conf'
(From OE-Core rev: 5115d2616b0847d521ccbecf1fbbf1f695a04fea)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the host system is expected to have enough capabilities that the
buildtools-tarball is not required, we don't need to bundle it.
This can save some significant space, especially when using with a minimal
eSDK.
minimal eSDK - core-image-minimal-qemux86-64
with buildtools-tarball - 34 MB installer - 281 MB installed
without buildtoools-tarball - 11 MB installer - 48 MB installed
(From OE-Core rev: e2b215054d11527a05210066b9bfd7d9a2054e01)
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
Write out the hash equiv cache file into any eSDK so that it doesn't rely
on having to call the hash server for the basic data requests.
(From OE-Core rev: 05c6842e747261b3350d6325e238429cf8728ca0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When doing a devtool build-sdk from within an esdk all nativesdk
components would be rebuilt. This patch introduces SDK_INCLUDE_NATIVESDK
flag to toggle the inclusion of nativesdk packages when creating the
esdk sstate
Currently locked-sigs.inc is generated during do_sdk_depends which
doesn't pull in nativesdk packages. Generating another locked-sigs.inc
in do_populate_sdk_ext and pruning it to only nativesdk* packages by
using a modified version of the already existing function
prune_locked_sigs and merging it with the current locked-sigs.inc
Also adding SDK_INCLUDE_NATIVESDK tasklistfn to the logic surrounding
setting tasklist file to not prune esdk sstate during creation
[YOCTO #13261]
(From OE-Core rev: d046afd12e1c209b29dca6ba402b9aa14680c5ce)
Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
eSDK
When you install the eSDK in publish mode and then try to build a
derivative sdk using devtool build-sdk, the following error happens
| NOTE: Generating sstate task list...
| NOTE: Generating sstate-cache...
| NOTE: Generating sstate-cache...
| DEBUG: Python function copy_buildsystem finished
| NOTE: Executing install_tools ...
| DEBUG: Executing shell function install_tools
| install: cannot stat /core/meta/files/ext-sdk-prepare.py':
No such file or directory
This patch will fix the error by installing ext-sdk-prepare.py in
publish mode, so that derivative sdk can be generated.
(From OE-Core rev: aab4089a57a655ca5a7792f05eb5d8dcdb934ae1)
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
local.conf
Some distros use site.conf to emit certain variables which are important
for eSDK e.g. DISTRO with out which eSDK will not be able to ger right
metadata when it tries to build
(From OE-Core rev: 95659bed3f6f3216b346f70cfc9ffae9788c0fc1)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running `bitbake -c populate_sdk_ext ...` for an image
recipe inheriting populate_sdk_qt5, `nativesdk-qemu-helper` is
deployed via `nativesdk-packagegroup-sdk-host`, which already
contains some of the tools (by name: "oe-find-native-sysroot
runqemu*").
To avoid error like:
Configuring nativesdk-packagegroup-qt5-toolchain-host.
NOTE: Running intercept scripts:
NOTE: > Executing update_gio_module_cache-nativesdk intercept ...
NOTE: + [ True = False ]
+ qemu-x86_64 -r 3.2.0 -E LD_LIBRARY_PATH=/home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/updatable-app-image/1.0-r0/sdk-ext/image/opt/mops/2.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib:/home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/updatable-app-image/1.0-r0/sdk-ext/image/opt/mops/2.5+snapshot/sysroots/x86_64-pokysdk-linux/lib -L /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/updatable-app-image/1.0-r0/sdk-ext/image /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/updatable-app-image/1.0-r0/sdk-ext/image/opt/mops/2.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/libexec/nativesdk-gio-querymodules /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/updatable-app-image/1.0-r0/sdk-ext/image/opt/mops/2.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/lib/gio/modules/
NOTE: Executing copy_buildsystem ...
DEBUG: Executing python function copy_buildsystem
NOTE: Generating sstate task list...
NOTE: Generating sstate-cache...
NOTE: Generating sstate-cache...
DEBUG: Python function copy_buildsystem finished
NOTE: Executing install_tools ...
DEBUG: Executing shell function install_tools
Traceback (most recent call last):
File "/home/sno/gpw-community-bsp/sources/poky/scripts/lnr", line 21, in <module>
os.symlink(target, linkname)
FileExistsError: [Errno 17] File exists: '../../../../layers/poky/scripts/oe-find-native-sysroot' -> '/home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/updatable-app-image/1.0-r0/sdk-ext/image//opt/mops/2.5+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/oe-find-native-sysroot'
WARNING: exit code 1 from a shell command.
DEBUG: Python function do_populate_sdk_ext finished
only add those tools unpackaged to the deployment which are
still missing.
(From OE-Core rev: 3274819ce3bb64316853c6f0bb7840c38635c26c)
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
The checksum value is only calculated if the uninative class is
inherited, so check for inherit before adding it to local.conf
(From OE-Core rev: 3b5b832589d943700b273e3a4d83561be0c47f36)
Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When generating the extended SDK, there is a copy step where this class
goes through the layers and other stuff that have been copied to
generate the SDK. The corebase; ie. the folder that contains the core
layer 'meta' is treated in a special way. Unfortunately in our tree, we
have:
sources/meta/meta
| `- core layer
`------- corebase
In populate_sdk_ext's copy_buildsystem, the heuristic to determine which
element of the list returned by copy_bitbake_and_layers is corebase is
fooled by such layout.
In copy_bitbake_and_layers, corebase is already handled specifically and
reliably, so we should let that function tell us which folder is
corebase instead of trying to determine it.
To do so, change the return type of copy_bitbake_and_layers to a tuple
that contains (corebase, copied_layers). It also simplifies the code on
the caller side.
(From OE-Core rev: 5368bc5d0d3606198b93e877bcafcd77bb5f4fd1)
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flag
Without this change, there will be two sstate index files in
tmp/sstate-control for any machine that contains a dash in the
name.
(From OE-Core rev: 29e7799bdb3773c40492e01448e0c614ed44583d)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As glibc 2.27 can't read older locale-archives, SDKs using glibc 2.27 on hosts
using glibc earlier than 2.27 won't be able to find any locales, so bitbake
won't start and Python can't use UTF-8.
So by default install all locales into the SDK. Special-case Extensible SDKs by
installing no locales as they ship glibc in a buildtools, and that will have the
locales.
Locale installation requires cross-localedef, so add that to DEPENDS.
Also remove the explicit en_US addition in buildtools-tarball as it is now
redundant.
(From OE-Core rev: 96896568d197cd06302713c24c0f7d91bfaea6c1)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
The current conflicting use of SDKDEPLOYDIR causes a race between do_populate_sdk
and do_populate_sdk_ext potentially causing the SDK to either go missing or the
build to fail.
(From OE-Core rev: 792cfbab488782a7bd610fc2078077d5497be4d1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make 'wic' image creation tool/command available in eSDK
environment. This would allow eSDK users to manipulate
images within eSDK environment.
[YOCTO #12177]
(From OE-Core rev: 90df6758a9f8753c646b129aa912e3849bf4c987)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous code:
os.rename(sdkbasepath, temp_sdkbasepath)
try:
foo
finally:
os.rename(temp_sdkbasepath, sdkbasepath)
always renamed the path, it made the debug harder when error happened.
drop the "try: finally" makes the debug easier.
(From OE-Core rev: 32126512349d65f0dbc31196c4ec6e1a1147cf5e)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For uninative to work, it relies on it being updated to new versions as
newer glibcs are built. This means the uninative generated by the current
build may not be as recent as the uninative that is being downloaded by
uninative.bbclass.
If this occurs, we can get symbol mismatch errors.
Ultimately, the sstate and the uninative versions need to match so we
should use the same tarball as uninative.bbclass is using, not the one
we built.
[YOCTO #12405]
(From OE-Core rev: a24c10b7bdab8aa960fdd3a58d2009f24344e579)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Alongside reworking the way devtool extracts source, we now need to
ensure that within the extensible SDK where task signatures are locked,
the signatures of the tasks for the recipes being worked on get unlocked
at the right time or otherwise we'll now get taskhash mismatches when
running devtool modify on a recipe that was included in the eSDK such as
the kernel (due to a separate bug). The existing mechanism for
auto-unlocking recipes was a little weak and was happening too late, so
I've reimplemented it so that:
(a) it gets triggered immediately when the recipe/append is created
(b) we avoid writing to the unlocked signatures file unnecessarily
(since it's a global configuration file) and
(c) within the eSDK configuration we whitelist SIGGEN_UNLOCKED_RECIPES
to avoid unnecessary reparses every time we perform one of the
devtool operations that does need to change this list.
Fixes [YOCTO #11883] (not the underlying cause, but this manifestation
of the issue).
(From OE-Core rev: 4e9a0be32fc30fb87d65da7cd1a4015c99533aff)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whilst this should work we see failures in testsdkext at the moment when
this is set. Add this to the blacklist for now until we can fix these issues
meaning we can at least test BB_SERVER_TIMEOUT in other scenarios.
Bug 119733 has been opened to track this.
(From OE-Core rev: 88cb174680cd37b5afb2b79e8248979895c35312)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows for other scripts to know that they are being executed in
the context of the eSDK in order to provide different behaviour as
needed.
[YOCTO #11155]
(From OE-Core rev: ebdd9b5a19eb6fb6c3249be4f0e2480a3de2aa8f)
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the new server structure we no longer need this separate
environment init script. Just set BB_SERVER_TIMEOUT to be greater
than zero and bitbake will remain in memory and the UI will auto-reconnect
to it.
Also clean out the old shutdown code from oe-init-build-env which
also doesn't make sense now.
(From OE-Core rev: a17724d687f9c04dc21f2f369da2b492f7119ba0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add get_extra_sdk_info to reuse code in buildhistory
The functionalities to generate SDK and eSDK manifest files are different,
the SDK comes from package information and the eSDK comes from sstate artifacts.
Only execute write_sdk_{host, target}_manifest when is on populate_sdk class.
Adds new functions write_sdk{host, target}_ext_manifest to execute on postprocess
in populate_sdk_ext because at the end we have all the sstate artifacts to
generate the manifest.
[YOCTO #9038]
(From OE-Core rev: 25ad7ed6f7bb0c931b404bda09576323200d093d)
Signed-off-by: Francisco Pedraza <francisco.j.pedraza.gonzalez@intel.com>
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If sstate was used to populate the build and one of the universal-4.8
or universal-4.9 mirror urls was used, the sstate checks during eSDK
construction could fail as it would zero out the SSTATE_MIRRORs
variable.
Use the same mirrors variable setting as the eSDK would end up using
to perform the checks to avoid this.
(From OE-Core rev: 6b9e8b780dcd8d5ffba3df35cfe41674413ee26d)
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>
|