The Source: variable is generated from FILE but this is excluded from checksums
normally which results in a reproduciubility issue when the filename changes.
Add in a dependency by reworking the code a little to avoid this.
(From OE-Core rev: 3ea7da76c6930031a0071069027b1d71f737fbc9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As this recipe tracks the release tags we can embed the PV in the
filename.
(From OE-Core rev: 6eae2b57d01be9906d0933be22a99e370b529b2e)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By setting this, event data from during the build is saved out. This can
be used for analytic including toaster to allow builds to be examined
later. This will use some disk space but it is worth it for the ability
to look into what happened during the build. Users can set the value to
something else in local.conf to override if they wish.
(From OE-Core rev: 4719b68bb9e3cccb85aed55350e53a439360abcb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I believe other fixes and cleanup means the CDN tests are now working
correctly, so enable it.
(From OE-Core rev: baabe012e158e387a692b234920eeab977c27440)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Check if project config tab right section contains five blocks:
- Machine:
- check 'Machine' is displayed
- check can change Machine
- Distro:
- check 'Distro' is displayed
- check can change Distro
- Most built recipes:
- check 'Most built recipes' is displayed
- check can select a recipe and build it
- Project release:
- check 'Project release' is displayed
- check project has right release displayed
- Layers:
- check can add a layer if exists
- check at least three layers are displayed
- openembedded-core
- meta-poky
- meta-yocto-bsp
(Bitbake rev: cbf0df0604e6cb37aa8c4433e9af3c321be80010)
Signed-off-by: Alassane Yattara <alassane.yattara@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In _parse_recipe(), bb_data was initially a datastore object, but then
after the call to bb.parse.handle() it was all of a sudden turned into a
dict of variant:datastore pairs. At the same time, parseRecipeVariants()
used bb_data for datastore objects, while parseRecipe() used it for the
dicts of variant:datastore pairs.
Change these functions to consistently use "bb_data" for datastore
objects and use "datastores" for the dicts of variant:datastore pairs.
(Bitbake rev: ed0f94c037476efd465db87726b2480406076beb)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Running `devtool search gcc` would result in errors like this for
virtual recipes:
ERROR: When reparsing
.../meta/recipes-devtools/gcc/libgcc-initial_13.2.bb:do_populate_sysroot,
the basehash value changed from
b1cd809ed98cef9db0fb1b17d34c4083e739c336f9d5619b89715b0294d81af5 to
44c2f92781dc4a20e98b7bb4724e204e64b101905fa75e71241a574b725997dc. The
metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake libgcc-initial -cdo_populate_sysroot -Snone
ERROR: Then:
ERROR: $ bitbake libgcc-initial -cdo_populate_sysroot -Sprintdiff
The reason was the newly introduced :layer-<layername> override, which
is used, e.g., in meta/classes-global/insane.bbclass to add the
patch-status QA test only for the meta layer:
ERROR_QA:append:layer-core = " patch-status"
When tinfoil parsed the recipes using the parseRecipeFile() function, it
failed to properly identify the layername for virtual recipes, which
resulted in the error above.
The correct thing to do is to make parseRecipeFile() call
bb.cache.virtualfn2realfn() to convert the virtual filename into a real
filename and virtual class.
(Bitbake rev: da2aed134412f5de04d7b540f92d735983ad0108)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we expand the variable AUTOREV in OE-Core, it triggers side effects in the
fetcher. The situation isn't ideal and needs improvement but this breaks
and is blocking enabling BB_DEFAULT_EVENTLOG.
Hack around the issue for now so we unblock things until we can work out
a better plan for how to improve AUTOREV support.
(Bitbake rev: cb9b6530f3d12c56a8b48847af2e7461924205d2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently it is only possible to specify an eventlog on the bitbake
commandline. Add a variable that can be used in bitbake.conf so that
we can log data by default more easily.
(Bitbake rev: ee174b231897a53cdde0f68769518342e53210cf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This test was occasionally failing for no obvious reason, so refactor
and improve:
- While waiting for the daemon, check that it is still running and
explicitly timeout after 10s when making the HTTP call.
- While waiting for the daemon to be ready, log the current state of the
daemon so we can tell if we're timing out as it is still scanning.
- This was in fact the cause of the intermittant failures, because the
TMPDIR is reused between tests and may contain a large number of
packages. Do the tests in an isolated TMPDIR to hopefully mitigate this
issue and increase the timeout to two minutes.
- Decorate the test using runqemu as such so that can be skipped in
environments without runqemu
- Add a second test that doesn't use runqemu or images, which is faster
but less realistic.
(From OE-Core rev: 88b660aaae2527736b6eccec4c952eee969e20a2)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we chdir(), do the chdir back to the original directory in a finally
block so they always run.
(From OE-Core rev: cdc40292818683b6df1c814498c7589450a163fa)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is essential to configure VSCode indexer plugins to ignore the build
folder of bitbake. Otherwise, the indexer plugins run with 100% CPU load
until an OOM exception occurs. In practice, this makes VSCode more or
less unusable for working with Yocto until a file like the one added by
this commit is deployed before VSCode starts. From the user's point of
view, it is not obvious why the system runs at 100% CPU load and
eventually crashes.
It is even more misleading that VSCode starts the indexers immediately,
but does not stop or reconfigure them when the ignore list is updated.
In practice, this means that every time the ignore list is changed,
VSCode immediately starts indexing the build folder until the OOM
exception stops it. Depending on the system's OOM handler, the entire
build machine may crash.
Particularly annoying is the Python plugin that ignores the general
ignore list and requires an extra ignore section.
The settings are suitable for workflows like bitbake, devtool modify,
devtool reset. The settings are not intended to work on the source code
of a recipe. It is assumed that a separate instance of VSCode is used
per workspace folder. These per workspace instances can have different
settings depending on the details of the sources that come with the
recipe.
VSCode can change the contents of the .vscode folder, which often leads
to a dirty git status. Normally, these changes are not added to git.
Otherwise, -f can be used to add them explicitly. It is not perfect if
the folder is listed in .gitignore. But it is also not better if it is
not.
(From OE-Core rev: 52cff14a73c9f286da4f627dc1aabf5c80aee63d)
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>
A previous commit attempted to fix reproducibility errors by forcing
regeneration of .po files. Unfortunately this triggered a different
type of reproducibility issue.
Work around this by adjusting the timestamps of the troublesome .po
files so they are not regenerated and we use the shipped upstream
versions of the files.
The shipped version of ru.cp1251.po doesn't seem to have been created
with the vim tooling and specifies CP1251 instead of cp1251, fix that.
(From OE-Core rev: 13d9551ba626f001c71bf908df16caf1d739cf13)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A previous commit tried to add the --follow-symlinks option to
the perform_passwd_expire function in useradd_base.bbclass, however it used
a single -.
This is interpreted as --file=ollow-symlinks which results in...
sed: couldn't open file ollow-symlinks: No such file or directory
and...
ERROR: <image name>: passwd --expire operation did not succeed.
Fix by adding the missing -
(From OE-Core rev: 3c0deafcfcea3f610c7dd9a2d2884a16fbfe0497)
Signed-off-by: Adam Johnston <adam.johnston@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
https://hypothesis.readthedocs.io/en/latest/changes.html#v6-89-0https://hypothesis.readthedocs.io/en/latest/changes.html#v6-88-4
6.89.0 - 2023-11-16
This release teaches from_type() to handle constraints implied by the
annotated-types package - as used by e.g. Pydantic. This is usually
efficient, but falls back to filtering in a few remaining cases.
Thanks to Viicos for pull request #3780!
6.88.4 - 2023-11-13
This patch adds a warning when @st.composite wraps a function annotated
as returning a SearchStrategy, since this is usually an error (issue #3786).
The function should return a value, and the decorator will convert it to a
function which returns a strategy.
(From OE-Core rev: 041e0a5ceeb55d40ab22071c5d2c358455bc8e23)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
