| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a bug in the current cache code where the restored data structures
were "inverted" leading to some very weird issues, not sure how anything worked
like that, this patch fixes it.
Also fix some issues with multiconfig cache ordering problems by resetting
the stream counters when appropriate.
(Bitbake rev: cd06beb948eff5eaf2d474f5b127d51a61b0b2ef)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've seen cases where the bitbake.sock file appears to disappear but the
server continues to hold bitbake.lock. The most likely explaination is
that some previous build directory was moved out the way, a server there
kept running, eventually exited and removed the sock file from the wrong
directory.
To guard against this, save the inode information for the sock file and check
it before deleting the file. The new code isn't entirely race free but should
guard against what is a rare but annoying potential issue.
(Bitbake rev: b02ebbffdae27e564450446bf84c4e98d094ee4a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
Tweak the code to remove duplication and only set if the attribute isn't
already there to avoid overwriting.
(Bitbake rev: 513e6c4e9233e0d0bc31e1169077fdbf9aaf4ec3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The data in SiggenRecipeInfo is large and has a lot of duplication. The size
causes a few problems, impacting:
- bitbake's overall memory usage
- the amount of data sent over IPC between parsing processes and the server
- the size of the cache files on disk
- the size of "sigdata" hash information files on disk
The data consists of strings (some large) or frozenset lists of variables.
To reduce the impact we can:
a) deplicate the data
b) pass references to the object on the second usage
(e.g. over IPC or saving into pickle).
This patch does this for SiggenRecipeInfo mostly behind the scenes
but we do need a couple of reset points so that streamed data is written
correctly on the second usage.
(Bitbake rev: 9a2b13af483c20763d6559a823310954884f6ab1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
Add a simple ping command so the UI can check the server is still there.
(Bitbake rev: fd3359de0b9f18fac187a629df203be0b2c87545)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
(Bitbake rev: 8f9402b291421ebcbf0a3ab97791c87af4b3f36e)
Signed-off-by: Frank de Brabander <debrabander@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Removed in BitBake through
https://git.openembedded.org/openembedded-core/commit/?id=3667e589ba16eb261cfd72c2b11429f482c239f6
(Bitbake rev: 50261fe047dfb41c3ce9d91b9b8245ce465d69b3)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
(Bitbake rev: 4f57853f46423f9e50b0140cd3d4aaffdcd5a08d)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Namespace in this context means a branch, a tag, etc., clarify
it in the description. Also, fix a typo "a any", replace with
plain "any".
This patch is based of feedback on new applied patch
d32e5b0e ("fetch2/git: Prevent git fetcher from fetching gitlab repository metadata")
(Bitbake rev: b4999425c812b25cb359d5163d11e3c1b030dc28)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The application order of override syntax :append, :prepend, :remove is
inobvious and undocumented. The order does not match variable parse
history, i.e. output of "bitbake -e", either.
Add note documenting the exact order in which :append, :prepend, :remove
are applied to variable in lib/bb/data_smart.py getVarFlag(). Add note
that this order does not match the variable parse history order. This
is mostly to prevent others from running into this and scratching their
heads, trying to find out what is going on.
Reviewed-by: Quentin Schulz <foss+yocto@0leil.net>
(Bitbake rev: 7379c2855b8497e56481d1ec7b5953e850550b85)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Converts the main bitbake program to use argparse instead of the
deprecated optparse.
The resulting Namespace returned by argparse should be equivalent to the
one returned from optparse; the only major difference is that the
positional "target" arguments are consumed by argparse and returned as
the "targets" property instead of an additional argument from
parse_args().
(Bitbake rev: bb2ea00274a594b7cc87a7cb0b165e9b28f6f3f4)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Log when the socket file already exists and is removed before
recreating a new socket.
Log when unlinking the socket file failed.
(Bitbake rev: cfd7c9899f988bab6d9fe7bbfbdb60603fb5ed34)
Signed-off-by: Frank de Brabander <debrabander@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
We need to be able to exclude dependencies from the python module
dependency code. Add support for the vardepexclude flag for these. It
only works from the configuration namespace rather than per recipe
for efficiency.
(Bitbake rev: 1aa672b01037fda4ca82f2c7e394783287c09ecd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moving code into python modules is a very effective way to reduce parsing
time and overhead in recipes. The downside has always been that any
dependency information on which variables those functions access is lost
and the hashes can therefore become less reliable.
This patch adds parsing of the imported module functions and that dependency
information is them injected back into the hash dependency information.
Intermodule function references are resolved to the full function
call names in our module namespace to ensure interfunction dependencies
are correctly handled too.
(Bitbake rev: 605c478ce14cdc3c02d6ef6d57146a76d436a83c)
(Bitbake rev: 91441e157e495b02db44e19e836afad366ee8924)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"fn" can mean different things in bitbake, we added support for class
extensions and then mutlticonfigs by extending it. In siggen, it generally
means that mc is prefixed to it and that it is a virtual filename.
Replace "fn" with "mcfn" in the code to make this clearer as if I'm getting
confused, everyone else likely is as well. "mcfn" is sometimes referred
to as taskfn as well but mcfn is probably the easiest to understand as the
taskname isn't included.
(Bitbake rev: e1c1139ab90f8da1b5036db11d943daefbe87859)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current method of passing either a task's datastore, or
dataCaches and a filename into the stamp functions is rather
horrible.
Due to the different contexts, fixing this is hard but we do control
the bitbake side of the API usage so we can migrate those to use other
functions and then only support a datastore in the public bb.build API
which is only called from task context in OE-Core.
(Bitbake rev: c79ecec580e4c2a141ae483ec0f6448f70593dcf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of the challenges in maintaining the code is that it sometimes uses
a datacaches structure and sometimes a datastore. Rather than continue
the current dual API madness, have the worker contexts create a dummy
datacaches structure with the entries we need. Whilst this does need to
be kept in sync with the real structure, that doesn't change and this
allows the code to be simplified.
With this new approach, we can unify the stamps dependency code again.
(Bitbake rev: c6d325fc9b53e9d588ab273ee3c2a99a70fba42c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
feature for signature dumping
Now that we have cache support for the taskdep/gendep/lookupcache data,
we can switch to use that cooker feature and skip the secondary reparse to
write the sig files. This does make the initial parse longer but means the
secondary one isn't needed.
At present parsing with the larger cache isn't optimal but we have plans
in place which will make this faster than the current reparse code being
removed here.
(Bitbake rev: 5951b5b56449855bc2a30146af65eb287a35fcef)
(Bitbake rev: 1252e5bce51ae912ecff9dcc354a371786ff2c72)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
It is becomming clear the siggen needs access to our cache data but we
can't always obtain it in the contexts we need to. Add it directly,
meaning over time we should be able to simplify the APIs and stop
convoluting new ones!
(Bitbake rev: 6b213590ed0e77683cf7fbce6bbe9605ddecf3d3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're struggling to understand how bitbake.sock can sometimes disappear
in live builds when we can't see where it could have been deleted.
This causes connection failures to the server and failed builds.
Add some extra debugging around the server log and client retry
log messages to give more information for the next time this issue
occurs.
(Bitbake rev: 376a516dc8c96727fd042ada65f803013601ee2d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Most of our older distros with python older than 3.8 already need buildtools
tarballs apart from Ubuntu 18.04. 3.8 allows us to fix a few things, tidy
code in places and is widely available or can be obtained with buildtools.
Therefore update our minimum version to 3.8.
(Bitbake rev: 744310f360d2288ac2ef07745abc86852126b5b9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
do_setscene was from a different era before our modern setscene
per task code. It hasn't been used for years so remove some old
obsolete references to it.
(Bitbake rev: ef72282298f7c4db74383c23bb0251dd06d3c6d3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
All siggens in common use should now support multiconfig, drop the
compatibility code.
(Bitbake rev: b36545b4df6d935ed312ff407d4e0474c3ed8d1a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When obtaining latest upstream versions, the code needs
to check if the existing tarball is in a versioned directory
(e.g. component-name/x.y/component-name-x.y.z.tar.gz) and
if it is, it needs to first obtain the list of all
such versioned directories and then check all of them by going
one step up in the directory hierarchy.
Existing code was returning a correct match when the component
name did not have numbers, e.g. a check on 'source/epiphany/43/'
would return 43, but was stopping too soon when the component
name itself had numbers ('source/libxml2/2.10/' would return libxml2).
This change ensures the last match is taken instead of the first.
Also, adjust the fetcher tests to check that versioned directories
are correctly traversed in this case (e.g. the step to go one level
up is taken and a new tarball is discovered in a different versioned
directory).
(Bitbake rev: b6601be22c6d776327acdcd1fa931400f41ac786)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
In the HTML page footer.
(Bitbake rev: 897f238e5e34d3f8f23e3b7ac8a19ef8bb0aca22)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
metadata
The bitbake git fetcher currently fetches 'refs/*:refs/*', i.e. every
single object in the remote repository. This works poorly with gitlab
and github, which use the remote git repository to track its metadata
like merge requests, CI pipelines and such.
Specifically, gitlab generates refs/merge-requests/*, refs/pipelines/*
and refs/keep-around/* and they all contain massive amount of data that
are useless for the bitbake build purposes. The amount of useless data
can in fact be so massive (e.g. with FDO mesa.git repository) that some
proxies may outright terminate the 'git fetch' connection, and make it
appear as if bitbake got stuck on 'git fetch' with no output.
To avoid fetching all these useless metadata, tweak the git fetcher such
that it only fetches refs/heads/* and refs/tags/* . Avoid using negative
refspecs as those are only available in new git versions.
Per feedback on the ML, Gerrit may push commits outsides of branches or
tags during CI runs, which currently works with the 'nobranch=1' fetcher
parameter. To retain this functionality, keep fetching everything in case
the 'nobranch=1' is present. This still avoids fetching massive amount of
data in the common case, since 'nobranch=1' is rare. Update 'nobranch'
documentation.
Reviewed-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
(Bitbake rev: d32e5b0ec2ab85ffad7e56ac5b3160860b732556)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In checkstatus() opener.open() is used to check if an artifact is available.
The check fails if the uri contains username password in the format:
"username:password@hostname..". Moreover, the checkstatus function already uses
the username from the "ud" object to craft a header, is username and password is
provided.
This fix ensure the uri in the Requests object used does not contain username as
password.
(Bitbake rev: 88350002d45e0aa85ecd5356da2c8d71e450641e)
Signed-off-by: Kasper Revsbech <kasper.revsbech.ext@siemensgamesa.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We keep seeing server issues where the lockfile is present but we can't
connect to it. Reuse the lockfile debugging code from the server to
dump better information to the console from the client side when we
run into this issue. Whilst not pretty, this might give us a chance
of being able to debug the problems further.
(Bitbake rev: 22685460b5ecb1aeb4ff3436088ecdacb43044d7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
We have timestamps in the server logs but we don't know which
UI messages correlate to them. Add some timestamps to the messages
which doesn't make them pretty but which might make it possible to
debug problems.
(Bitbake rev: a1a86f8c311cb1fc4f5562f1c77f82aa95141eee)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some layers think they're going to be 'clever' and copy the values from
another layer, e.g. using ${LAYERSERIES_COMPAT_core}. The whole point of
this mechanism is to make it clear which releases a layer supports and
show when a layer master branch is bitrotting and is unmaintained.
Therefore add some code to avoid people doing this. I wish we didn't have
to but...
(Bitbake rev: 6709aedccbb2e7ddbb1b2e7e4893481a7b536436)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BB_GLOBAL_PYMODULES
For many years OE-Core has injected it's own python modules into the
python namespace using an immediate expansion of a variable in base.bbclass.
It also added all entries from BBPATH to sys.path.
We really need this to become a first class citizen of the langauge, this new
addpylib directive allows that. Usage is of the form:
addpylib <directory> <namespace>
The namespace is imported and if there is an attribute BBIMPORT, that
list of names is iterated and imported too.
This mirrors what OE-Core has done for a long time with one difference in
implmentation, sys.path is only appended to. This means later imported
namespaces can't overwrite an earlier one and can't overwrite the main
python module space. In practice we've never done that and it isn't
something we should encourage or support.
The new directive is only applied for .conf files and not other filetypes
as it only makes sense in that context. It is also only allowed in the
"base configuration" context of cookerdata since adding it at the recipe
level wouldn't work properly due to the way it changes the global namespace.
At the same time, move the list of modules to place in the global namespace
into a BB_GLOBAL_PYMODULES variable. It is intended that only the core layer
should touch this and it is meant to be a very small list, usually os and sys.
BB_GLOBAL_PYMODULES is expected to be set before the first addpylib directive.
Layers adding a lib directory will now need to use this directive as BBPATH
is not going to be added automatically by OE-Core in future. The directives are
immediate operations so it does make modules available sooner than the current
OE-Core approach.
The new code appends to sys.path rather than prepends as core did, as
overwriting python standard library modules would be a bad idea and naturally
encouraging people to collaborate around our own core modules is desireable.
(Bitbake rev: afb8478d3853f6edf3669b93588314627d617d6b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
| |
(Bitbake rev: 5d27c555f7e1cc2064a39a1ce862e09a399185f7)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Get rid of the duplicate code and add extra check that the
locale en_US.UTF-8 is available on the system. This new helper
method is now located right above the method filter_environment()
which sets LC_ALL environment variable to 'en_US.UTF-8'.
[YOCTO #10165]
(Bitbake rev: a4ce040a6fd540a1cac52f808f909f9fcf8c961c)
Signed-off-by: Frank de Brabander <debrabander@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Starts the sync thread slightly earlier to give it some extra time to
dump out the caches while the main process tears down the parsing
processes
(Bitbake rev: 105f2897b0618713b036fc0f7a6e0f3e78d1707a)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Uses an event to terminate the parser threads instead of a queue. This
is not only simpler, but saves about 500ms on shutdown time
(Bitbake rev: 2aed34e1d4bf24bba6263f168ff31b55b5fbe982)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bitbake cache
Being able to track siggen hash construction data can be useful for cache
debugging. For now, add an extra cache class which contains this information.
It can be enabled in the same way as the hob data cache through a feature flag
to cooker. This allows us to experiment with the data without carrying larger
patches around and ultimately may allow use to have a hash mismatch debugging
mode that is more easily enabled.
(Bitbake rev: 0736a8a03da8b774fafbd28f746bef4705378049)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The basehash data is really internal bitbake data and passing an object
directly is more efficient than creating and then extracting variables.
This will match the format of other data we may optionally wish to
store in the cache so more to the more efficient method. Nothing I
can see is using this data today (and nothing should be).
(Bitbake rev: e621093a1bf37cd75ede3fb77ab6845556870fc7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Make a small change in the layout of the code in build_dependencies
which makes subsequent patches easier to read. No functionality change,
just moving the function definitions to the start of the function block.
(Bitbake rev: fff13b1e5e8397130b4378e0ba2301336ec651a2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Explain how to run the testsuite clear enough so no external
documentation is required.
(Bitbake rev: 51cf7cf12d23b757aa49f428a256fb3d3c865f6d)
Signed-off-by: Frank de Brabander <debrabander@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the expand cache doesn't work for "parser" return types, which
is the main type used by the build_dependencies() call that we spend most
of the time in when parsing. Tweak the code to cache the unexpanded value
in the expand cache and hence allow reuse of the parser in other fast path
cases for small speed gains.
(Bitbake rev: b4a8e5071dbcba2217b79e83e08b275ffcbc0eef)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you place a multiconfig which isn't enabled into an mcdepends you currently
get a traceback from runqueue. We can do better, add some code to tell the user
what happened in a more readable way without the traceback.
[YOCTO #14970]
(Bitbake rev: a4693b70764bb394ee2cf8dd12a5f6fce866008b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
These are static regex compilations which don't change or a standard module
import (bb). There is noneed to declare them as global so drop the pointless
code which doesn't do anything.
(Bitbake rev: 09a4c159e3fd184f730821e7bd99916b0d28dc70)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
This code looks like it is from a time when the data module was executable.
Nobody does that now and this usage of pydoc is long since obsolete/broken
so clean up the code which doesn't do anything useful.
(Bitbake rev: 6f4ef770641a9657edaf8618f4c86dfb1116622c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
One section of the code is enforcing lowercase overrides, the other
is allowing numeric characters. We should be consistent with one or
the other.
(Bitbake rev: df5b3b841fd8d6a652d643e9ae2bba09d60043e0)
Signed-off-by: 张忠山 <zzs213@126.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some variables may be set as:
X = 1
as well the more usual
X = "1"
so add support to to_boolean to handle this case.
(Bitbake rev: ef9c033b011e68bbfedf7ddf118633c14388aaaf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
If someone is unfortunate enough to run into override recursion issues
they're hard to debug with the existing message. We can at least show the
values that OVERRIDES takes to show there is some problem and aid debugging.
(Bitbake rev: 43035b75201616e7bfd680d3d15c5c0fc7c04eb6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
The parse_recipe has been removed from bb.cache, replace it with
the databuilder._parse_recipe.
(Bitbake rev: d386fa81848247a3d407debf889db8cbcce03359)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python handles frozensets a little more optimally than normal sets. Once we
finish parsing, we don't edit this data so we can convert to them.
To do that, we need to stop changing them so process ignore_deps earlier
then we can freeze the data and keep it frozen.
This has the side effect that we need to be careful to sort the data
in some of the variables when calculating the hashes.
Overall this does seem to show a decent parsing time speed improvement
of 20-25% in a local test but this would be highly setup dependent.
Also ensure the sigdata can handle exported frozenset and make it import
back to them instead of sets.
(Bitbake rev: 19475627c363a52da49ec144422c87448ff2a6c5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We identified a use case where a native recipe (autoconf-native) was
rebuilt with no change in output yet the sstate for do_package tasks
wasn't being used.
The issue is that do_package tasks have a hard dependency on
pseudo-native:do_populate_sysroot. That task was one of the many
tasks being rehashed when autoconf-native's hash was changed.
If update_tasks processed a recipe before it had processed pseudo-native,
that recipe would be marked as not possible from sstate and would
run the full tasks.
The fix is to split the processing into two passes, first to handle
the existing covered/notcovered updates, then in the second pass,
check whether there are "harddep" issues.
This defers the do_package tasks until after pseudo-native is installed
from sstate as expected and everything works well again.
(Bitbake rev: e479d1e418a7d34f0a4663b4a0e22bb11503c8ab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even after enabling all our debugging, we had a reproducible test case
where sstate wasn't being reused and it was unclear from the logs why.
This patch adds debugging on the possible codepaths that were breaking
and allowed the issue to be debugged and fixed.
(Bitbake rev: 9233ad685b9b5e9eeb775fc71761712aaf0e876c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|