ver 0.62:
Add support for cleanup functions and macros.
Add support for setting DHCP max attempts.
(From OE-Core rev: ae84d13b6c4f33a56cc36715a118a9f938ceb2c4)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Renaming the 'rootrw' kernel commandline parameter to
'overlayrootrwdev' to both align better with this modules name, and
point out the usage of the variable.
This patch also includes an if block to migrate the old 'rootrw'
block, should it be already used by someone.
(From OE-Core rev: a52b7f5c8ff3e50707b55843d9996983ab8efae2)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The initramfs-framwork takes kernel commandline options and converts
them for internal use to variables following the 'bootparam_name'
pattern. The overlayroot module uses 'bootparam_rootfstype' and
'bootparam_rootfsflags' which both collide with linux kernel
parameters 'rootfstype' and 'rootfsflags'. This collision is solved
by putting the variables in the namespace of the initramfs-framework
module.
(From OE-Core rev: ef20ef719c699b94fc52b81c520faa0b3714efeb)
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fetch from premirror few times to emulate multiple machines sharing same
clonedir or few rebuilds of the package from (pre)mirror
Regression test for [Yocto #15369]
(Bitbake rev: 7fcbac574c68f16b95ab7abb2874931d168d3c9e)
Signed-off-by: Pavel Zhukov <pavel@zhukoff.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix the issue with using of (pre)mirror in case if clonedir exists but
outdated.
Previous version of the code fetched new mirror content into FETCH_HEAD
instead of branch which caused refetch from the upstream. Add new remote
add fetch from it instead so the ref can be found by "_contains_ref"
Fixes [Yocto #15369]
(Bitbake rev: 69588e2a5c7c200e47b02b2391498dcb72388bd2)
Signed-off-by: Pavel Zhukov <pavel@zhukoff.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When git is configured with safe.bareRepository=explicit [1], the
git-make-shallow fails miserably. LWN has an article about the
problem that this configuration option addresses and why it is useful
in [2].
It also seems that it is being rolled out in some environments as a
default for users.
In order to allow having this configuration turned on for a user's
environment in general, the fetcher has to be tought to use --git-dir=
for all relevent git operations.
The alternative, implemented here, is to forcibly turn off that option
for all git operations. In the future, we could look into converting
these to using the --git-dir= command line argument instead.
Link: https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/config/safe.txt#n1 [1]
Link: https://lwn.net/Articles/892755/ [2]
(Bitbake rev: 7c63989db4590564516ed150930f4e2fa503e98f)
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When git is configured with safe.bareRepository=explicit [1], the
bitbake selftests fail miserably. LWN has an article about the
problem that this configuration option addresses and why it is useful
in [2].
It also seems that it is being rolled out in some environments as a
default for users.
In order to allow having this configuration turned on for a user's
environment in general, the fetcher has to be tought to use --git-dir=
for all relevent git operations.
The alternative, implemented here, is to forcibly turn off that option
for all git operations. In the future, we could look into converting
these to using the --git-dir= command line argument instead.
Link: https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/config/safe.txt#n1 [1]
Link: https://lwn.net/Articles/892755/ [2]
(Bitbake rev: a45e14a7343e36101e45639931322e5649587f57)
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When git is configured with safe.bareRepository=explicit [1], the
bitbake git fetcher fails miserably. LWN has an article about the
problem that this configuration option addresses and why it is useful
in [2].
It also seems that it is being rolled out in some environments as a
default for users.
In order to allow having this configuration turned on for a user's
environment in general, the fetcher has to be tought to use --git-dir=
for all relevent git operations.
The alternative, implemented here, is to forcibly turn off that option
for all git operations. In the future, we could look into converting
these to using the --git-dir= command line argument instead.
While at it, fix one open-coded invocation of git that wasn't using
ud.basecmd
Link: https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/config/safe.txt#n1 [1]
Link: https://lwn.net/Articles/892755/ [2]
(Bitbake rev: 5f3b1d8dc9ee70e707536bd75ee845b547440c97)
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to hashserv API changes in siggen, we need bitbake 2.7.3.
(From OE-Core rev: 7172fd527fde440f26dd6cc371cde2720dbaa366)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Implements the new API required for querying unihashes in parallel
(From OE-Core rev: 0c66d07238d20dc1b34355e4c472aa7457d2e5fe)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Hash Equivalence server performs unconditional insert also of duplicate
hash entries. This causes excessive error log entries in Postgres.
Rather ignore the duplicate inserts.
The alternate behavior should be isolated to the postgres
engine type.
(Bitbake rev: e8d2d178d0fe96f9d6031c97328e8be17d752716)
Signed-off-by: Tobias Hagelborn <tobiasha@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds API to query if unihashes are known to the server in parallel
(Bitbake rev: 7e2479109b40ce82507f73b4f935903f7f79fb06)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Implements a new API called get_unihashes() that allows for querying
multiple unihashes in parallel.
The API is also reworked to make it easier for derived classes to
interface with the new API in a consistent manner. Instead of overriding
get_unihash() to add custom handling for local hash calculating (e.g.
caches) derived classes should now override get_cached_unihash(), and
return the local unihash or None if there isn't one.
(Bitbake rev: 6faf48c09a4003a31b32e450779fb8ac9cc5e946)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Implements a Client Pool derived from the AsyncRPC client pool that
allows querying for multiple equivalent hashes in parallel
(Bitbake rev: ba4c764d8061c7b88cd4985ca493d6ea6e317106)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds an abstract base class that can be used to implement a pool of
client connections. The class implements a thread that runs an async
event loop, and allows derived classes to schedule work on the loop and
wait for the work to be finished.
(Bitbake rev: f113456417f9ac0a4b44b291a6e22ea8219c3a5f)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds API to check if the server is aware of the existence of a given
unihash. This can be used as an optimization for sstate where a client
can query the hash equivalence server to check if a unihash exists
before querying the sstate cache. If the hash server isn't aware of the
existence of a unihash, then there is very likely not a matching sstate
object, so this should be able to significantly cut down on the number
of negative hits on the sstate cache.
(Bitbake rev: cfe0ac071cfb998e4a1dd263f8860b140843361a)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the _execute() helper to execute queries. This helper does the
logging of the statement that was being done manually everywhere.
(Bitbake rev: 0409a00d62f45afb1b172acbcea17bf17942e846)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds support for removing unused unihashes from the database. This is
done using a "mark and sweep" style of garbage collection where a
collection is started by marking which unihashes should be kept in the
database, then performing a sweep to remove any unmarked hashes.
(Bitbake rev: 433d4a075a1acfbd2a2913061739353a84bb01ed)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Coming from a kernel background, I was thinking along the lines of
dmesg -n <integer>
for loglevel adjustments. So I tried various large and small and
even zero number values with no luck before getting frustrated and
opening up the python.
Let us save others the frustration and give a hint what the args it
expects should look like.
(Bitbake rev: df184b2a4e80fca847cfe90644110b74a1af613e)
Signed-off-by: Paul Gortmaker <paulg@kernel.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Existing conf-notes.txt is not adequate in situations where the user
needs to select a config template from several, or get an overview of them and
is interested only in a brief explanation of what the template is for,
but not extended multi-paragraph instructions for how to use it.
Such summaries can be provided via conf-summary.txt and
this patch adds such a summary for the poky default template.
Updates to the tools and a tool for selecting templates which
will make specific use of the summary will follow.
(From meta-yocto rev: 5f404da45021caa09c796dee015ff735d36fa4c0)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This includes a simple test which creates a layer setup using
custom references, and subsequently modifies the resulting layers
setup using a different custom reference.
(From OE-Core rev: 36701e78cf239261ad21cf58db2934c3c8a5e3e6)
Signed-off-by: Jermain Horsman <jermain.horsman@nedap.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This creates a new layers setup with, or, modifies an existing layers
setup using, one or more repositories where the references are provided
by the user.
This is a very minimal implementation, no validation of any reference
is done and it is left to the user to provide a valid value.
(From OE-Core rev: e69444de713e1ec7959c71f9cdf965d3b5a1c6be)
Signed-off-by: Jermain Horsman <jermain.horsman@nedap.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is another piece of the puzzle in setting up builds from nothing
without having to write custom scripts or use external tools.
After layers have been fetched and placed into their respective locations by
oe-setup-layers, one would surely want to proceed to the actual build, and here's how:
1. Without arguments the tool reads available layers
from .oe-layers.json file (written out by oe-setup-layers or a fallback under scripts/),
prints what templates it has found, and asks the user to select one, as seen below.
This will land the user in a shell ready to run bitbake:
=============================================
alex@Zen2:/srv/work/alex$ ./setup-build
Available build configurations:
1. alex-configuration-gadget
This configuration will set up a build for the purposes of supporting gadget.
2. alex-configuration-gizmo
This configuration allows building a gizmo.
3. poky-default
This is the default build configuration for the Poky reference distribution.
Re-run with 'list -v' to see additional information.
Please choose a configuration by its number: 1
Running: TEMPLATECONF=/srv/work/alex/meta-alex/conf/templates/configuration-gadget . /srv/work/alex/poky/oe-init-build-env /srv/work/alex/build-alex-configuration-gadget && /bin/bash
You had no conf/local.conf file. This configuration file has therefore been
created for you from /srv/work/alex/meta-alex/conf/templates/configuration-gadget/local.conf.sample
You may wish to edit it to, for example, select a different MACHINE (target
hardware).
You had no conf/bblayers.conf file. This configuration file has therefore been
created for you from /srv/work/alex/meta-alex/conf/templates/configuration-gadget/bblayers.conf.sample
To add additional metadata layers into your configuration please add entries
to conf/bblayers.conf.
The Yocto Project has extensive documentation about OE including a reference
manual which can be found at:
https://docs.yoctoproject.org
For more information about OpenEmbedded see the website:
https://www.openembedded.org/
This configuration will set up a build for the purposes of supporting gadget.
Please refer to meta-alex/README for additional details and available bitbake targets.
==============================================
2. It is also possible to list available configurations without selecting one using
'setup-build list' or to select and setup one non-interactively with 'setup-build setup'.
3. The full set of command line options is:
$ ./setup-build --help
usage: setup-build [-h] [--layerlist LAYERLIST] {list,setup} ...
A script that discovers available build configurations and sets up a build environment based on one of them. Run without arguments to choose one interactively.
positional arguments:
{list,setup}
list List available configurations
setup Set up a build environment and open a shell session with it, ready to run builds.
optional arguments:
-h, --help show this help message and exit
--layerlist LAYERLIST
Where to look for available layers (as written out by setup-layers script) (default is /srv/work/alex/.oe-layers.json).
$ ./setup-build list --help
usage: setup-build list [-h] [-v]
optional arguments:
-h, --help show this help message and exit
-v Print detailed information and usage notes for each available build configuration.
$ ./setup-build setup --help
usage: setup-build setup [-h] [-c configuration_name] [-b build_path] [--no-shell]
optional arguments:
-h, --help show this help message and exit
-c configuration_name
Use a build configuration configuration_name to set up a build environment (run this script with 'list' to see what is available)
-b build_path Set up a build directory in build_path (run this script with 'list -v' to see where it would be by default)
--no-shell Create a build directory but do not start a shell session with the build environment from it.
4. There's an an added hint in oe-setup-layers about how to proceed (as it is really not user-friendly
to fetch the layer repos successfully and then exit without a word), and a symlink to the script
from the top level layer checkout directory.
5. The selftest to check layer setup has been adjusted to run a basic check for template
discovery and build setup. The revision of poky to be cloned has been bumped to 4.1,
as that's the first version with a default template in a standard location.
(From OE-Core rev: 1360b64e88cda7dddfb0eca6a64f70c13dafb890)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
They are handled exactly same as conf-notes.txt.
(From OE-Core rev: 6fd2eb619693da4cb918b421f3e31072b48fa85a)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Existing conf-notes.txt is not adequate in situations where the user
needs to select a config template from several, or get an overview of them and
is interested only in a brief explanation of what the template is for,
but not extended multi-paragraph instructions for how to use it.
Such summaries can be provided via conf-summary.txt and
this patch adds such a summary for the oe-core default template.
Updates to the tools and a tool for selecting templates which
will make specific use of the summary will follow.
(From OE-Core rev: aa96c2064a874714cfe4bac2fa622690e4c27ee4)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Do not only log that there has been an issue but add WARNING before for local
runs. Hopefully this helps to avoid that people reading the log to quickly miss
issues.
Fixes [YOCTO #15389]
(From OE-Core rev: 661c0a8fd8fe7bff61cea82778c25cf24d791267)
Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a selftest for the recently introduced check for CVE_CHECK_IGNORE.
(From OE-Core rev: dc6ebbbb94b162d8aa68e46d5a166606ace5e39c)
Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is beneficial for setting up builds, as this list can be used
to determine reliably where the actual layers are, and discover
available configurations from them.
Also adjust the selftest to check the presence of that file rather
than any specific layer in a hardcoded location.
Sample output (paths are written relative to the file for relocatability
and ease of reading):
{
"layers": [
"meta-openembedded/meta-filesystems",
"meta-openembedded/meta-gnome",
"meta-openembedded/meta-initramfs",
"meta-openembedded/meta-multimedia",
"meta-openembedded/meta-networking",
"meta-openembedded/meta-oe",
"meta-openembedded/meta-perl",
"meta-openembedded/meta-python",
"meta-openembedded/meta-webserver",
"meta-openembedded/meta-xfce",
"poky/bitbake/lib/layerindexlib/tests/testdata/layer1",
"poky/bitbake/lib/layerindexlib/tests/testdata/layer2",
"poky/bitbake/lib/layerindexlib/tests/testdata/layer3",
"poky/bitbake/lib/layerindexlib/tests/testdata/layer4",
"poky/meta-poky",
"poky/meta-selftest",
"poky/meta-skeleton",
"poky/meta-yocto-bsp",
"poky/meta"
],
"version": "1.0"
}
(From OE-Core rev: 82743f4f767f8016564be0d9d6c0d8fe9e067740)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All are already fixed in 8.2.1, NVD was informed that cpes are wrong.
(From OE-Core rev: a975960baffd341cd07cb093bef107c031c9b956)
Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Provide a reasonable default configuration for VSCode and the
yocto.bitbake extension.
The generated default configuration is generic and minimal. It's mostly
supposed to prevent VSCode from OOM exceptions if the build directory is
in the scope of the indexer plugins of VSCode.
But it also configures the yocto-bitbake plugin to just work without
manual user interaction.
The configuration is only generated if VSCode is installed. Currently,
VSCode is one of many popular editors for Yocto/OE. Removing the check
would mean that the configuration would be generated by e.g. oe-selftest
or for users not using VSCode. If it should prove useful, the check can
be removed later.
Customization for other layers is possible. A layer might provide it's
own oe-setup-build-env script which calls the oe-setup-vscode script
from poky with different folders. But it's also possible to override the
oe-setup-vscode script by another layer with a custom implementation.
(From OE-Core rev: 48829be7ab2edcbc2e4473f81cdaf35889d63f9c)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a new official bitbake plugin:
https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake
This plugin automatically updates the .vscode/settings.json file.
Having the settings.json file in git and a plugin which modifies this
file is not ideal. It can lead to anoying situations especially when
working with git. For example a git stash reverts the settings which are
automatically applied by the plugin. While git stashed the settings.json
file the plugin immediately changes the file again and tries to run
bitbake based on the newly generated settings. When git does a stash pop
the restored settings.json file conflicts with the new settigns.json
file which has been generated while the git stash took place.
Therefore this patch removes the .vscode folder from git.
Removing the settings.json leads to other issues as already described
in the commit message of 5ff688fe29. But we still need another solution
where the settings.json file is not in Git.
Discussion is here:
https://github.com/yoctoproject/vscode-bitbake/issues/95
(From OE-Core rev: f36771e155b9e0cf24a885bf3340d59036aa42c5)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Also correct the comment describing what is happening.
(From OE-Core rev: 7d867753fba8d536bef4c72c7bea3f4ed26a1a95)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default, the tests are built and run at do_compile and we can see
errors like below in log.do_compile:
gnupg-2.4.4/tests/cms/inittests: line 99: ../../sm/gpgsm: cannot execute binary file: Exec format error
Note that the do_compile process still succeeds. However, we'd better avoid
executing these target binaries at build time.
(From OE-Core rev: 74d48497470ce209bc6bdf49c2e2cfda67dce6ae)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
https://www.vim.org/vim-9.1-released.php
Vim 9.1 is available
The Vim project is happy to announce that Vim 9.1 has finally been released.
This release is dedicated to Bram Moolenaar, Vim's lead developer for more
than 30 years, who passed away half a year ago. The Vim project wouldn't
exist without his work!
Vim 9.1 is mainly a bug fix release, it contains hundreds of bug fixes, a
few new features and there are many minor improvements.
Changes:
https://github.com/vim/vim/compare/v9.0.2130...v9.1.0114
CVE: CVE-2024-22667
(includes commit b39b240c38)
(From OE-Core rev: 9f7e9c0f4360469b9775372272e0a442c7cc06c8)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update libgit2 to pull in securtiy fixes.
Changelog summary:
- A bug in git_revparse_single is fixed that could cause a Denial of
Service attack. This fixes CVE-2024-24575
- A bug in git_index_add is fixed that could lead to arbitrary code execution.
This fixes CVE-2024-24577
- A bug in the smart transport negotiation could have caused an out-of-bounds
read.
(From OE-Core rev: 7191dcae3853728dbb95c4901c2fdb73f9066a66)
Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Redhat/Fedora specific as it affects the grub2-set-bootflag extension
added by Redhat to grub.
(From OE-Core rev: 40cd768368167f81de5bb55e9ff0584035f4c1b4)
Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The rust tests nearly pass for qemurisv64, add the remaining ones to the
exclusion list so it matches everythig else in exlcuding all the know
to break cases.
(From OE-Core rev: 1d6c6e4418c9865a4aeae627e0f130b2181d3657)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Create an ncurses version of the GTK app "taskexp.py".
* Add these additional features:
- Sort tasks in recipes by their dependency order
- Print individual and/or recipe-wide dependencies to a file
- Add a wild card filter
- Show the target recipes on BOLD
* Provide a GUI self test
* Provide a non-ncurses self test for ptest
(Bitbake rev: f49bec66ad51c8cddeceafbbe2445c46e396ee8b)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The autobuilder has been seeing increasing numbers of testsdk failures
where xz was 'missing':
ERROR: core-image-sato-1.0-r0 do_testsdk: Couldn't install the SDK:
Error: xz is required for installation of this SDK, please install it first
This is probably due to xz and it's libraries not being in the sysroots
in a way which works without races.
Since the SDK should be using the host, fix this. The eSDK already does
this to solve a similar problem so copy the code from there.
(From OE-Core rev: 39ac3439dfdf2afa67abed4bd32aeb3c14979ded)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add some oe-selftests for the new devtool ide-sdk plugin. Most of the
workflows are covered.
Many thanks to Enguerrand de Ribaucourt for testing and bug fixing.
(From OE-Core rev: 458fa66b117ccad690720931f912de09655691dc)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new devtool ide plugin provides the eSDK and configures an IDE to
work with the eSDK. In doing so, bitbake should be used to generate the
IDE configuration and update the SDK, but it should no longer play a
role when working on the source code. The work on the source code should
take place exclusively with the IDE, which, for example, calls cmake
directly to compile the code and execute the unit tests from the IDE.
The plugin works for recipes inheriting the cmake or the meson bbclass.
Support for more programming languages and build tools may be added in
the future.
There are various IDEs that can be used for the development of embedded
Linux applications. Therefore, devtool ide-sdk, like devtool itself,
supports plugins to support IDEs.
VSCode is the default IDE for this first implementation. Additionally,
some generic helper scripts can be generated with --ide none instead of
a specific IDE configuration. This can be used for any IDE that
supports calling some scripts.
There are two different modes supported:
- devtool modify mode (default):
devtool ide-sdk configures the IDE to manage the build-tool used by the
recipe (e.g. cmake or meson). The workflow looks like:
$ devtool modify a-recipe
$ devtool ide-sdk a-recipe a-image
$ code "$BUILDDIR/workspace/sources/a-recipe"
Work in VSCode, after installing the proposed plugins
Deploying the artifacts to the target device and running a remote
debugging session is supported as well.
This first implementation still calls bitbake and devtool to copy the
binary artifacts to the target device. In contrast to compiling,
installation and copying must be performed with the file rights of the
target device. The pseudo tool must be used for this. Therefore
bitbake -c install a-recipe && devtool deploy-target a-recipe
are called by the IDE for the deployment. This might be improved later
on.
Executing the unit tests out of the IDE is supported via Qemu user if
the build tool supports that. CMake (if cmake-qemu.bbclass is
inherited) and Meson support Qemu usermode.
- Shared sysroots mode: bootstraps the eSDK with shared sysroots for
all the recipes passed to devtool ide-sdk. This is basically a wrapper
for bitbake meta-ide-support && bitbake build-sysroots. The workflow
looks like:
$ devtool ide-sdk --share-sysroots a-recipe another-recipe
vscode where/the/sources/are
If the IDE and the build tool support it, the IDE gets configured to
offer the cross tool-chain provided by the eSDK. In case of VSCode and
cmake a cmake-kit is generated. This offers to use the cross
tool-chain from the UI of the IDE.
Many thanks to Enguerrand de Ribaucourt for testing and bug fixing.
(From OE-Core rev: 3f8af7a36589cd05fd07d16cbdd03d6b3dff1f82)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The purpose of the change is to never sign a package not created by
the build itself.
sstate_create_package is refactored into Python and re-designed
to handle signing inside the function. Thus, the signing should never apply
to existing sstate packages. The function is therefore renamed into
sstate_create_and_sign_package.
The creation of the archive remains in a separate shellscript function.
Co-authored-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
(From OE-Core rev: ba223f8fff19ea59440d56cf3fe46200f3f71e22)
Signed-off-by: Tobias Hagelborn <tobias.hagelborn@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
