Instead of having a test called eg "assimp", rename it to "cmake" as the
point of the test is to verify that CMake works. This should make it
clearer what the tests are actually exercising.
(From OE-Core rev: ccf7fdc0e5b6df218b319f972cd5ba142c06c243)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To enable this test to work with gcc 14, pass the option to make
warnings non-fatal. Also upgrade to version 5.4.1 from 5.3.1.
(From OE-Core rev: c3df6287ae26dc9d7f11eb7e26fdbcaefe4dfead)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
librdfa hasn't had a commit for a decade now and as such has problems
with modern compilers (specifically gcc 14.1). Switch the recipe
creation test to something much simpler that we also control: dbus-wait.
(From OE-Core rev: d801de1f702d8d0def55011b5b6ad39d85f978f1)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Several recipes have S pointing at a directory that does not exist.
Set S in these cases to somethig valid making the metadata and
recipe behaviour more consistent.
Tweak one of the QA test diff offsets to match the changed recipe.
(From OE-Core rev: 22f1f5849a9a3bf287dbe8933546e52e39ddc86e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The only real reason for oe-local-files was to support S = WORKDIR. With changes to
drop support for that, it makes sense to simplify devtool and to try and make both
the code and the processes/workflows simpler.
This patch drops support for S = WORKDIR, removes oe-local-files and then updates
the test cases to match this new situation.
At the code level, we assume we can always now track code changes using git and
that things committed into git are handled as patches (as before) but delta against
HEAD is saved as specific file level changes to the recipe.
One test is disabled as it is no longer approproate. It is being keped until we can
make WORKDIR != UNPACKDIR at which point it should be revisited.
(From OE-Core rev: ce8190c519052fed10b5233697b69a75868db45a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace references of WORKDIR with UNPACKDIR where it makes sense to do
so in preparation for changing the default value of UNPACKDIR.
(From OE-Core rev: 1f18b9a512800860d5153d89eb82b56388efad6f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similarly to centos 8, centos 9 doesn't support the render device we need
for this test.
(From OE-Core rev: c2be3afabf84f287c90b61ae2509728a6634fb8f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sometimes the debuginfod selftest fails due to a timeout, because it
spends too long scanning a huge deploy directory that due to what tests
were ran previously can contain 30K packages.
The test only needs a subset of the feed, so use the new localpkgfeed
class to construct a minimal feed before running the test.
[ YOCTO #14937 ]
(From OE-Core rev: 855376f518b28248ccd82ef5b2e89e6a8c970542)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If usrmerge is in DISTRO_FEATURES, assumptions in one of the tests would
fail. Improve the test so it works in both cases.
(From OE-Core rev: afa211746a2aa1993a54cc5a5e1937679341da8e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If usrmerge is in DISTRO_FEATURES, assumptions in one of the tests would
fail. Improve the test so it works in both cases.
(From OE-Core rev: 68a27d307a7042e242c49cf3d069469f40e09902)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit ab6d3e3d64
from poky repository.
The previous reverted commit was a workaround. The fix
"oeqa/selftest/devtool: fix _test_devtool_add_git_url"
tackle the issue. So, the workaround is not needed anymore.
(From OE-Core rev: 731f47ecfd8ad6558aac629806810789c623986b)
Signed-off-by: Alexandre Truong <alexandre.truong@smile.fr>
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch is a follow-up to the bug#15466.
As a reminder, the bug was about devtool’s submodule detection
checking for HEAD when a version is being passed.
As Vincent Kriek pointed out:
the --version that is being passed to devtool is only used for
setting the PV value in the recipe. To take into account the tag,
we add --srcrev to the command:
devtool add --srcrev v3.1.0 --version v3.1.0 mbedtls git://git@github.com/ARMmbed/mbedtls.git;protocol=https
Changes to _test_devtool_add_git_url have been made to take
into account the srcrev. srcrev will be passed as an optional
parameter because the test_devtool_add_git_style1
does not need the srcrev contrary to test_devtool_add_git_style2
Fixes [YOCTO #15466]
(From OE-Core rev: a8686f3641e4407dee3d807898ffd620e2732b78)
Signed-off-by: Alexandre Truong <alexandre.truong@smile.fr>
Reported-by: Alexandre Truong <alexandre.truong@smile.fr>
Suggested-by: Vincent Kriek <vincent@coelebs.dev>
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't have a test to check if we can correctly devtool update-recipe/finish
into another layer. So update the existing test_devtool_update_recipe_local_files
to also check the updates into another layer.
(From OE-Core rev: bd44c895d36e246a25c7a6e40bf9f4089dc7a297)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If testtools and/or subunit modules are not found we get the following backtrace
(example for testtools):
NOTE: Starting bitbake server...
Traceback (most recent call last):
File "<..>/poky/scripts/oe-selftest", line 60, in
<module>
ret = main()
File "<..>/poky/scripts/oe-selftest", line 47, in main
results = args.func(logger, args)
File "<..>/poky/meta/lib/oeqa/selftest/context.py",
line 391, in run
rc = self._internal_run(logger, args)
File "<..>/poky/meta/lib/oeqa/selftest/context.py",
line 377, in _internal_run
rc = self.tc.runTests(**self.tc_kwargs['run'])
File "<..>/poky/meta/lib/oeqa/selftest/context.py",
line 161, in runTests
return super(OESelftestTestContext, self).runTests(processes, skips)
File "<..>/poky/meta/lib/oeqa/core/context.py", line
91, in runTests
result = self.runner.run(self.prepareSuite(self.suites, processes))
File "<..>/poky/meta/lib/oeqa/selftest/context.py",
line 154, in prepareSuite
from oeqa.core.utils.concurrencytest import ConcurrentTestSuite
File
"<..>/poky/meta/lib/oeqa/core/utils/concurrencytest.py",
line 22, in <module>
import testtools
ModuleNotFoundError: No module named 'testtools'
Fix this by adding a custom callback on -j/--num-processes parameter to
check testtools and subunit modules. Fallback to serial testing if
missing. This strategy is already used in sdk/context.py
(From OE-Core rev: 35284404473b2c2d9f69594582868ed66ef3525e)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-l option is specific to df provided by coreutils, if df
applet from busybox is used then it does not work and fails
like below
Fixes
df: invalid option -- 'l'
BusyBox v1.36.1 () multi-call binary.
Usage: df [-PkmhT] [-t TYPE] [FILESYSTEM]...
DEBUG: [Command returned '1' after 0.71 seconds]
DEBUG: Command: df -hl
Status: 1 Output: df: invalid option -- 'l'
it seems worth a compromise to show remote mounted filesystems if any
during ptests and it works with both df implementations
(From OE-Core rev: 75cc1ea4348a2294fdc5ab20530fcff27056ff06)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The problem is the following:
AssertionError: 'gitsm://git@github.com/ARMmbed/mbedtls.git;protocol=https;branch=master' != 'git://git@github.com/ARMmbed/mbedtls.git;protocol=https;branch=master'
Mbedlts made changes to their repository, adding a sub-module, thus the
assert triggers an error with the url:
git://git@github.com/ARMmbed/mbedtls.git;protocol=https;branch=master
456a54da8e
was the upstream change.
To fix the issue, the url has been changed to:
gitsm://git@github.com/ARMmbed/mbedtls.git;protocol=https;branch=master
(From OE-Core rev: 9ac737fbe05c85ec8333b396ce2f89de6654916f)
Signed-off-by: Alexandre Truong <alexandre.truong@smile.fr>
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Under some load conditions, the result event can come back before the
command complete event. If that happens, the code would hang
indefinitely.
Rework the code to wait for both events and avoid the hang.
(From OE-Core rev: 8cfc94a4404c54bc73eab9f98d9da1f84c2135ad)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds to run_test_sstate_creation so that it also tests
that sstate directories don't accidentally pickup umask permissions
from the user upon creation.
[RP: Python style tweaking]
(From OE-Core rev: 7d6eb828e97ad3f27d94efdccd920fb2aef36743)
Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The dbus-wait command returns a timeout after 60s but reports "success", detect this.
Unfortunately it does effectively break the test as the signal is nearly never being
correctly detected since it was already sent.
For that reason comment out the code instead too.
Also fix the loop conditional as the logic was incorrect and it was looping
indefinitely when an image match didn't occur.
(From OE-Core rev: 89c930e9e4b38b116edcba59e88621a39f8bda67)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch uses dbus-wait to wait for matchbox to be up. Once that
happens, it sets a timeout of 60 seconds and takes a screenshot
and compares it, every 2 seconds. If diff=0 it passes. If the timeout
ends, it fails.
(From OE-Core rev: 287b4f0a8244f7214f6a1aaa84ef16cc528f8326)
Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Excluding riscv64 due to mouse rather than a touchscreen which adds a
moving cursor, so the diff ends up > 0. Need to fix the image to use the
touchscreen rather than mouse input.
(From OE-Core rev: 7f7032c7613abd62ce510c98211c75fc7c5e7090)
Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The mouse panel icon can move when the time changes between 3 and 4 digits.
Ideally we'd fix the alignment of the clock on the panel but to get the
tests working, increase the size of the mask for now.
(From OE-Core rev: 8ec02142ab98741749281bdb29d5973c96b839d7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Allow tools to be found from the host PATH so that imagemagick from a buildtools
tarball/sdk can work
* Reformat the code to have imports at the start of the file and have more standard
formatting and whitespace
* Always save copies of the images, the space imapct is negligle compared to the
debug win
* Write the images to ${T}
* Use bb.utils.mkdirhier() instead of more complex code
* Restrict the tests to images containing matchbox-desktop
(From OE-Core rev: d09989b49517830297654e4d1d150aaa8723c41a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This takes the work rburton did on image screenshot testing and
expands it.
Right now this works with most of the qemu based machines except for
- qemuppc64
- qemuarmv5
- qemuriscv32
- qemuloongarch64
See "Known Issues" further down.
This test takes a screendump of a qemu image, blanks out the clock
and compares it to an image we have on record. If the diff is exact,
the test passes. If not, it stores the image in build/failed-images and
fails out.
In order to enable this test, you will need meta-openembedded/meta-oe in
your bblayers.conf for imagemagick and the following in local.conf:
IMAGE_CLASSES += "testimage"
TEST_SUITES = "login"
TESTIMAGEDEPENDS:append:qemuall = " imagemagick-native:do_populate_sysroot "
Known Issues
------------
The main issue is that I've yet to find a gating factor that would allow
me to tell when the qemu instance is fully up and rendered. I've tried a
few tactics here, (dbus-wait, qmp) but for now a disgusting
time.sleep(30) is there.
You can replicate this by running qemumips. The screen load takes forever,
but you even see it on qemux86 where the Home and Workspace Switch icons
will sometimes take a while to fully load.
Eventually I'm going to have to take multiple screenshots and compare
them, but then you get into the issue where the question is, is the diff
greater than 0 because it hasn't fully loaded or something is actually
incorrect.
There are the issues I know about:
- runqemu qemuppc64 comes up blank.
- qemuarmv5 comes up with multiple heads but sending "head" to screendump.
seems to create a png with a bad header.
- qemuriscv32 and qemuloongarch64 don't work with testimage apparently?
- qemumips64 is missing mouse icon.
- qemumips takes forever to render and is missing mouse icon.
- qemuarm and qemuppc return incorrect width
- All images have home and screen flipper icons not always rendered fully at first.
The sleep seems to help this out some, depending on machine load.
(From OE-Core rev: dc7cefbaccde50df6c4396e66d50659a45e00631)
Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
Co-authored-by: Ross Burton <ross.burton@arm.com>
Co-authored-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A change in QEMUMonitorProtocol.cmd() requires that we either pass in
kwargs instead of an argument dict or move to cmd_raw()
cmd() was renamed to cmd_raw() (and command() was renamed to cmd())
See:
37274707f6684750ab4f
My concern with this patch is that I haven't seen this come up with
utils/dump.py which also uses QemuMonitor's run_monitor. If it is
occuring, this should fix issues there as well
(From OE-Core rev: 9665d38ab60c1c3b27887c2b1a6396f13a1b33ea)
Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adjust selftest to git-add the directory with newly added patches,
as the new minicom recipe has no default patches, and thus no directory
with them (and the selftest assumed it does).
(From OE-Core rev: 1fb2aa3f242ef20f8edfb518164b629258a04dd4)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since go-1.21 GOPROXY needs to be set explicitly, otherwise it fails with:
- GOPROXY list is not the empty string, but contains no entries
This fixes the selftest
(From OE-Core rev: c491d967858c01fead21495f44f1a9f8cdf8e833)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The recently introduced postactions module can raise, on failing ptests,
the following warning:
WARNING: core-image-ptest-glib-2.0-1.0-r0 do_testimage: Can not get host
disk usage: [Errno 2] No such file or directory: '/usr/bin/df'
The issue is likely not happening because of df absence (to be confirmed
amongst the variety of workers) but because of the wrong path. Fix it by
letting subprocess search for df, passing only the binary name. To make it
work, we also have to reset the environment, otherwise the environment
configured before running bitbake will be used, and search will fail.
(From OE-Core rev: da7cc5def2839a0e15d07244f858847479c12caa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve the GDB related tests. Verify GDB finds the correct source
files.
(From OE-Core rev: 67eed460c0bf18d23f2c9180f195417895acfd55)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since the target under test can be a virtualized guest, when some tests
fail because of disk usage (see [1]), also fetch disk usage statistics from
host to allow checking whether a host disk space saturation could affect
running tests.
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15220
(From OE-Core rev: 2ab3a0935b1e7a016402f149da1fc01b38d7af55)
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to be able to create actions that could store new files during
failed test post actions, we need to split artifacts directory creation
from artifacts retrieval.
Create a new dedicated action to create artifacts main directory so we can
add actions creating files in this new directory, without worrying about
actions order if at least this action is set first.
(From OE-Core rev: 5d796586a9342f4f984494a5b493dbaf77af7026)
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
testimage is able to detect whenever a test run leads to some tests
failing, and execute some actions in this case. The only action currently
defined in such case is to retrieve artifacts from the target under test,
as listed in TESTIMAGE_FAILED_QA_ARTIFACTS
In order to be able to add multiple actions, define a central function to
gather all "post actions" to run whenever a test has failed
(run_failed_tests_post_actions). This function contains a table listing all
functions to be called whenever a test fails. Any function in this table
will be provided with bitbake internal data dictionary ("d") and the
current runtime testing context ("tc"). Isolate all this feature in a
dedicated postactions.py file inherited by testimage.
This patch does not bring any functional change.
(From OE-Core rev: c01aa8df0613a103859b4431d3cc5056b2fef1b8)
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Multiple places in oeqa need to get the log output path, and redefine a
small helper to accomplish this
Define this helper in lib/oeqa/utils/__init__.py and import it wherever
needed to allow using it.
(From OE-Core rev: 01b1a6a5a4e7cede4d23a981b5144ae9c8306274)
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds a test for 13904's fix by creating a convoluted set of recipes
with USERADD_DEPENDS in non-alpha order.
(From OE-Core rev: bfff81195cb9ba2493e366022470b2e0051d8071)
Signed-off-by: Eilís 'pidge' Ní Fhlannagáin <pidge@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a new base-files bbappend was added to meta-poky, it causes selftest
failures. Whilst this isn't ideal, workaround that issue for now since
the append is being added for security visibility and changing the tests
to support this more generically looks invasive.
(From OE-Core rev: 7cf85204f0943bf741ffce5c4105340197c714df)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The rust testsuite was redirecting command output to a file, which made it
hard to debug failure cases since the logs were not available to print to
the console.
Rework the code so it uses the existing popen logging and hence allows us
to improve the error logging situation and make debugging failures easier.
(From OE-Core rev: ac82dc43b8151ed34c4ad51e9ab7f4a612990486)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Add support to detect the "mesonpy" build-backend for recipetool create.
* Add oe-selftest case for creating a recipe for "siphash24" from pypi.
https://pypi.org/project/siphash24/
This is by far the simplest recipe using the mesonpy build backend.
Upstream does not provide LICENSE file(s) and we do not detect the
LICENSE so don't check for that result in the test. Likewise, upstream
does not define HOMEPAGE, so skip that result.
(From OE-Core rev: 256749322671d2f4ea994db671d73c4de10e1723)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python 2 is gone and we don't need the abstraction now, drop the remaining usage
of this variable.
The definition in python3-dir.bbclass is left for now for other layers.
(From OE-Core rev: b566b1e32c7993d1ab7795562f648e52ce186a70)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The old way of keeping track of the filenames for the patches that
correspond to the commits was to add a special comment line to the end
of the commit message, e.g., "%% original patch: <filename>", using a
temporary git hook. This method had some drawbacks, e.g.:
* It caused problems if one wanted to push the commits upstream as the
comment line had to be manually removed.
* The comment line would end up in patches if someone used git
format-path rather than devtool finish to generate the patches.
* The comment line could interfere with global Git hooks used to
validate the format of the Git commit message.
* When regenerating patches with `devtool finish --force-patch-refresh`,
the process typically resulted in adding empty lines to the end of the
commit messages in the updated patches.
A better way of keeping track of the patch filenames is to use Git
notes. This way the commit messages remain unaffected, but the
information is still shown when, e.g., doing `git log`. A special Git
notes space, refs/notes/devtool, is used to not intefere with the
default Git notes. It is configured to be shown in, e.g., `git log` and
to survive rewrites (i.e., `git commit --amend` and `git rebase`).
Since there is no longer any need for a temporary Git hook, the code
that manipulated the .git/hooks directory has also been removed. To
avoid potential problems due to global Git hooks, --no-verify was added
to the `git commit` command.
To not cause troubles for those who have done `devtool modify` for a
recipe with the old solution and then do `devtool finish` with the new
solution, the code will fall back to look for the old strings in the
commit message if no Git note can be found.
While not technically motivated like above, the way to keep track of
ignored commits is also changed to use Git notes to avoid having
different methods to store similar information.
(From OE-Core rev: f5e6183b9557477bef74024a587de0bfcc2b7c0d)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a commit is marked with "%% ignore" it means it is used by devtool to
keep track of changes to the source code that are not the result of
running do_patch(). These changes need to actually be ignored when
extracting the patches as they typically make no sense as actual patches
in a recipe.
This also adds a new test for oe-selftest that verifies that there are
no patches generated from ignored commits.
(From OE-Core rev: c3d43de7e54189bf09fbe8e87ddb976e42ebf531)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
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 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>
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>
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>
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>
